kOS Scriptable Autopilot System 0.9

[Dunbaratu]

I suppose you could determine your surface prograde direction by subtracting your 'orbital velocity' from the rotation speed of kerbin, based on your latitude and extended up to your altitude...

This would be far faster to calculate and much cleaner than what I ended up resorting to. But the problem is that you can't obtain the three XYZ components of you orbital velocity vector. If you *could* then you could just subtract the surface speed of the planet (plus a bit for your altitude as you point out) from just the X component and that would be that. Done. But there's no access to the 3 parts of the vector so that isn't an accessible solution right now. I did think of that possible solution and rejected it for that reason.

If I do get access to the XYZ components later I may change the code to this simpler solution.

and then taking into account the change in longitude and latitude over time... (which won't be precise... it'll be jittery based on how long it takes your computer to run each command in kOS). Anyway, I'd be interested to see your solution.

I ended up having to do it this way. I work out how much distance is covered by the delta in latitude and longitude angles.

[Dunbaratu]

if currentbody = "Kerbin" { set radiusplanet to 600000. set gplanet to 9.81. }.
if currentbody = "Mun" { set radiusplanet to 200000. set gplanet to 1.63. }.
if currentbody = "Minmus" { set radiusplanet to 60000. set gplanet to 0.491. }.
if currentbody = "Eve" { set radiusplanet to 700000. set gplanet to 16.7. }.
if currentbody = "Gilly" { set radiusplanet to 13000. set gplanet to 0.049. }.
if currentbody = "Moho" { set radiusplanet to 250000. set gplanet to 2.70. }.
if currentbody = "Duna" { set radiusplanet to 320000. set gplanet to 2.94. }.
if currentbody = "Ike" { set radiusplanet to 130000. set gplanet to 1.10. }.
if currentbody = "Dres" { set radiusplanet to 138000. set gplanet to 1.13. }.
if currentbody = "Laythe" { set radiusplanet to 500000. set gplanet to 7.85. }.
if currentbody = "Vall" { set radiusplanet to 300000. set gplanet to 2.31. }.
if currentbody = "Tylo" { set radiusplanet to 600000. set gplanet to 7.85. }.
if currentbody = "Bop" { set radiusplanet to 65000. set gplanet to 0.589. }.
if currentbody = "Pol" { set radiusplanet to 44000. set gplanet to 0.373. }.
if currentbody = "Eeloo" { set radiusplanet to 210000. set gplanet to 1.69. }.

Incidentally, I thought it would be really useful to have a generic publicly-maintained file everyone could share that does this sort of thing with planetary stats and lets you run it up at the top of your program, giving everyone a sort of standardized set of variable names to use for this sort of thing. Here's the example I started building for my own purposes. Right now it only has Kerbin and the Mun and I was going to add more as needed:

(YES I know comments like this don't really exist. I have a small Perl script I run to publish my code to the archive directory and as part of doing that it strips the comments out. Thus I can have comments in my source without the language ever seeing them.)

# bodystats: sets up variables for use in programs
# that need stats about the orbital body that is the
# current SOI.  Looks up the body name and fills
# the appropriate variables.
clearscreen.
print "Settings for current SOI body: " + body.
print " ".

# Placeholder Defaults in case I didn't code stats for current body.
# ------------------------------------------------------------------
set bodySurfaceGrav to 10.  # The m/s^2 at the body's surface.
set bodyRadius to 500000 .  # The radius from center to equator.
set descendAGL to 50000 .   # The highest AGL at which descents might start.
set hoverAGL to 100 .       # the AGL where a descending craft should hover.
set descendTopSpeed to 2000.0 .  # Desired speed at top of descent profile.
set descendBottomSpeed to 4.0 .  # Desried speed at bottom of desecnt profile.
set bodyLandingSpeed to 4.0.     # Desried speed to come down from hover to
set bodyAvgGround to 1500.  # The body's average ground altitude to use
                            # When the radar is too far away to read the
                            # real ground altitude.
set throttleGentle to 80.   # Throttle gentleness.
                            # too low and the throttle is twitchy.
                            # too high and its too slow to react.

set c to " ====== deviations for each body ===== ".
if body = "Kerbin" {
  set bodySurfaceGrav to 9.802 .
  set bodyRadius to 600000 .
  set descendAGL to 70000 .
  set hoverAGL to 50.
  set descendTopSpeed to 1800.0 .
  set descendBottomSpeed to 2.0 .
  set descendLandingSpeed to 4.0 .
}.
if body = "Mun" {
  set bodySurfaceGrav to 1.63 .
  set bodyRadius to 200000 .
  set descendAGL to 20000 .
  set hoverAGL to 15 .
  set descendTopSpeed to 542.0 .
  set descendBottomSpeed to 2.0 .
  set bodyLandingSpeed to 2.0.
}.

print " ".
print "bodySurfaceGrav    = " + bodySurfaceGrav.
print "bodyRadius         = " + bodyRadius.
print "descendAGL         = " + descendAGL.
print "hoverAGL           = " + hoverAGL.
print "descendTopSpeed    = " + descendTopSpeed.
print "descendBottomSpeed = " + descendBottomSpeed.
print "bodyLandingSpeed   = " + bodyLandingSpeed.
print "throttleGentle     = " + throttleGentle.
print " ".
print "('AGL' means Above Ground Level to distinguish ".
print "from sea level altitude.)".
print " ".
print "You may change these variables with the 'set' ".
print "command before running other programs to try ".
print "other settings.".
print " ".

Obviously some of the settings in there are meant for things my own scripts need and probably would need to be stripped out if this was made generic and public. Also the print statements don't need to be there but I liked having them during my testing.

Things I was thinking could be in it:

bodySurfGrav (i.e. 9.802 on Earth or Kerbin).

bodyRadius

bodyMass (You need this if you want to calcluate the gravity at other altitudes besides sea level, for example if you wanted to calculate where geosynchronous orbit is.)

bodyAtmoHeight (altitude above sea level where atmosphere ends. Zero or -1 for airless bodies.)

bodyAtmoPres (how much atmosphere pressure at sea level? from this plus atmoHeight you can calculate it for other altitudes.)

bodyYear (Number of seconds for body to orbit the sun. Perhaps useful when planning movements.).

and so on. Anything else that would be useful?

Also, it shouldn't JUST depend on the current body. There should also be a way to do a lookup for other bodies to get stats on target planets. So since there's no real arguments you might devise a system you call something like this:

// Example to get Kerbin's grav and Mun's grav into two different variables:

set bodyQuery to "Kerbin".

run bodystats.

set kGrav to bodySurfGrav

set bodyQuery to "Mun".

run bodystats.

set mGrav to bodySurfGrav.

Would a thing like this be useful to people? The reason for the klunky extra lines (set a variable, run the program, copy the variable into a result) is to get a cheezy way to pass parameters without having real parameter passing.

Edited September 15, 2013 by Steven Mading

[check]

I ended up having to do it this way. I work out how much distance is covered by the delta in latitude and longitude angles.

Took a look at your code, but didn't run it yet. Very nice. But how jittery are your velocity measurements? I tried doing something similar to calculate acceleration and it was all over the place. In the long run, it averaged out to what it should be but instantaneously it just jumped around too much to be much use.

Incidentally, I thought it would be really useful to have a generic publicly-maintained file everyone could share that does this sort of thing with planetary stats and lets you run it up at the top of your program, giving everyone a sort of standardized set of variable names to use for this sort of thing.

Nice. Will definitely be useful once we get the right code to allow for automated interplanetary missions.

[Dunbaratu]

Took a look at your code, but didn't run it yet. Very nice. But how jittery are your velocity measurements? I tried doing something similar to calculate acceleration and it was all over the place. In the long run, it averaged out to what it should be but instantaneously it just jumped around too much to be much use.

The trick was my addition of putting the delta time in the calculations. That way even though each loop iteration doesn't necessarily take the same amount of time, that is accounted for. While it might be true for example that in one iteration the craft moved 50 meters while in the next iteration it moved 100 meters, I found that usually that was happening because the second one took twice as long as the first, not because it was giving incorrect or widely swinging data. Once I divided by the amount of time elapsed between iterations (via the missiontime variable), the differences smoothed out and became far less swingy. Its still a little inaccurate but it's more workable than it used to be when I assumed a fixed iteration time.

Nice. Will definitely be useful once we get the right code to allow for automated interplanetary missions.

In the interest of making this not be just a mechjeb clone (the whole point is to write the autopilot yourself), I prefer opening up the raw data and letting people work it out themselves.

For example, if KOS would let us find the current time from the start of campaign (rather than just the missiontime), that would mean you could find the current position of a planet by running the on-rails calculation given the planetary stats, its start position, and the current time.

[Motokid600]

Oooook I thought it was about time I tried this. Ive been skeptical for weeks now because of the complexity of it, but all I want this thing to do for me is launches... for now.

First off... out of no where this mod lags the game to hell when activated. It was fine the first few times, but my last try resulted in single digit fps...

Im hoping it clears up.. So besides that to start out with I copied Kevin's script from the introductory video. But I made a few changes to comply with my craft. Here it is.. bare with me.

clearscreen.

print "3". wait 1.

print "2". wait 1.

print "1". wait 1.

lock throttle to 1.

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

stage.

print "Lift Off!".

wait until altitude > 9600.

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

print "Pitching over..".

wait until altitude > 40000.

stage.

print "Fairing Jettison.".

wait until stage:liquidfuel < 5.

stage.

print "Stage 1 seperation!".

wait until apoapsis > 69000.

lock throttle to 0.

lock steering to prograde.

print "waiting for OIB..".

wait until eta:apoapsis < 3.

lock throttle to 1.

print "Burning..".

wait until periapsis > 70000.

lock throttle to 0.

Now I made this in a readme file to later copy into the editor. Which brings me to my questions..

How do I copy txt into this? It Ctrl-V doesn't work.

Why is it colons ( : ) do not work? the video is pre .21 so im guessing there was an update?

Directions.. which way to tell the rocket to turn and to what angle.

I copied in Kevin's script

wait until altitude > 9600.

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

print "Pitching over..".

This is for an eastward gravity turn, but what if I want to go north? I know that the roll is set to 180, but at what point do the R values ( R(?,?,? ) ) indicate direction? And im guessing -50 would be my pitch?

That's it really.. the only other thing is.. how are you guys putting your code into the little boxes?

O and.. is there a smaller, radial part for the module? Just like a little circuit board like EngRedux?

Edited September 16, 2013 by Motokid600

[check]

The trick was my addition of putting the delta time in the calculations. That way even though each loop iteration doesn't necessarily take the same amount of time, that is accounted for. While it might be true for example that in one iteration the craft moved 50 meters while in the next iteration it moved 100 meters, I found that usually that was happening because the second one took twice as long as the first, not because it was giving incorrect or widely swinging data. Once I divided by the amount of time elapsed between iterations (via the missiontime variable), the differences smoothed out and became far less swingy. Its still a little inaccurate but it's more workable than it used to be when I assumed a fixed iteration time.

That's pretty much what I did, but I still found that it moved around too much too be useful... but I had it set up like:

 
If blah blah {
set time1 to missiontime.
set v1 to verticalspeed.
set time2 to missiontime.
set v2 to verticalspeed.
set a to (v2-v1)/(time2-time1).
blah blah blah
blah blah blah
}.

But I guess if I have time1 & v1 and time2 & v2 spaced farther apart (with the blah blah blah code in the middle) it might smooth out the numbers more.

In the interest of making this not be just a mechjeb clone (the whole point is to write the autopilot yourself), I prefer opening up the raw data and letting people work it out themselves.

For example, if KOS would let us find the current time from the start of campaign (rather than just the missiontime), that would mean you could find the current position of a planet by running the on-rails calculation given the planetary stats, its start position, and the current time.

Yeah, I'm sure a 'universal time' function is on its way. It's probably pretty easy to do.

[Dunbaratu]

But I guess if I have time1 & v1 and time2 & v2 spaced farther apart (with the blah blah blah code in the middle) it might smooth out the numbers more.

In my case because I was in the midst of a loop anyway I just got the snapshots once per iteration and checked current versus prev iterations. I think that helps because it meant the time is farther apart, and that smooths out the variations better.

[Dunbaratu]

Oooook I thought it was about time I tried this. Ive been skeptical for weeks now because of the complexity of it, but all I want this thing to do for me is launches... for now.

Ironically it would be easier if it was MORE complex. It's the simplicity that makes it hard because it does so little you have to work out how to obtain missing information yourself.

First off... out of no where this mod lags the game to hell when activated. It was fine the first few times, but my last try resulted in single digit fps...

I have not experienced this. Could there be a problem between KOS and another mod on your install?

How do I copy txt into this? It Ctrl-V doesn't work.

The editor in the terminal window is extremely limited. Most people have been editing the code behind the scenes in the text editor of their choice instead.

If you go to Plugins/PluginData/Archive you see a text file for each program you wrote and saved in the archive volume. You can just pull those up in a text editor and edit them outside the game. Or make a new file called something.txt and save it there, and it will become a program called 'something' in the game.

Why is it colons ( : ) do not work? the video is pre .21 so im guessing there was an update?

What do you mean by "don't work?" You can't type them? Or you can but they don't function right?

Directions.. which way to tell the rocket to turn and to what angle.

I copied in Kevin's script

This is for an eastward gravity turn, but what if I want to go north? I know that the roll is set to 180, but at what point do the R values ( R(?,?,? ) ) indicate direction? And im guessing -50 would be my pitch?

The rotation system using R() tuples is *REALLY* messed up unless you're a computer graphics professional or a mathematician who's experienced a thing called "Euler Rotations" before. It doesn't work like normal mathematical rotations work, because it bends axes into non-orthogonal shapes making it messy to work out how to rotate around two axes. If you've had introductory understandings of the math of 3D space you'll think the word "rotate" means all three axes rotate together and remain orthogonal to each other. But Euler Rotations don't do that, and in a sense are slightly mis-named. They're not really rotations but rather they are distortions of space and understanding them is an advanced topic.

So instead it's far easier to use the V() system to just point at a vector of your choosing. It works like so:

lock steering to up * V( x,y,z).

This will let you just point along a vector.

That's it really.. the only other thing is.. how are you guys putting your code into the little boxes?

The markup is [ C O D E ] (minus the spaces) to start the section and [ / C O D E ] (minus the spaces) to end it.

[Sma]

It's really easy. Just have your loop update the xyz values as shown. You may not need the limits for function. They are there for the print out. I haven't tested to see what happens when you go beyond the 360 limit. My program doesn't have limits. I assume most people will know that >360 and <0 are invalid. 90 degree yaw equates to North on the Nav Ball. I have wrapped my yaw value in a target heading. Which is just set yaw to 90 + tHeading. You can then set tHeading to whatever you wish and that corresponds to the Nav Ball heading. Pitch is 90 up so that works out. Pitch is set via heading.

I set a heading of 45 at my first turn and ended up in an inclination of 44.6deg. I'd say that's not too bad. I have not tested adding roll into the mix as of yet. I feel it might be the only thing R(,,) is good for.

I guess I'm doing something wrong. Trying to launch a rocket using your code with V() and the other functions. After 2seconds in to flight the rocket starts to roll (spinning around the z axis) and then is all over the place, but after about 30-38 seconds it stabilizes (with nothing more than just going through the loop again, took out the +5) with north being at the top of the nav ball. When I print tAngle ( up + V(x,y,z) ) it's coming out atsR(0.103,43.333,0). When I set pitch to 45 R comes out as (0.122,356.833,0) or there abouts (it keeps changing).

I set yaw to 180 and pitch to 90 before launch. I've tried adding 5 to both pitch and yaw during the loop with out much of a change for stability. I'm imagining the stability is due to it reorienting so that north is at the top of the nav ball. Could it just be a case of me making it more complicated than it should be? LOL I'm known to do that sometimes.

[Motokid600]

I have not experienced this. Could there be a problem between KOS and another mod on your install?

Actually maybe. I have romfarer installed with an extended view distance... couldn't help. Ill try a few things..

If you go to Plugins/PluginData/Archive you see a text file for each program you wrote and saved in the archive volume. You can just pull those up in a text editor and edit them outside the game. Or make a new file called something.txt and save it there, and it will become a program called 'something' in the game.

Ive tried looking for the programs ive saved in the game, but nothing. Plugins/PluginData/Archive is empty. And ive tried just saving that code I wrote up there in a .txt file, but it says cannot be found when I try to run it.

What do you mean by "don't work?" You can't type them? Or you can but they don't function right?

The key doesn't function. It simply adds a space. Semicolon works, but no colon.

So instead it's far easier to use the V() system to just point at a vector of your choosing. It works like so:

lock steering to up * V( x,y,z).

This will let you just point along a vector.

And how does x,y,z reflect onto the navball? Because im thinking in terms of headings. 0 degrees North, 90 east, 180 south, 270 west. But if I understand what you explained to me that is the wrong way to go about it.

Edited September 16, 2013 by Motokid600

[Bizz Keryear]

First thing 1st. I think it is a bit strange for a plugin created after 0.20 to use the old legacy directories.

Instead of <KSP directrory>/plugins it should be in <KSP directrory>/GameData/KOS/plugins

2nd: And somehow this plugin act strange at my side.

I have written this Program:

until altitude > 10000 {

print altitude at (0,1).

print VERTICALSPEED at (40,1).

if VERTICALSPEED > 210 {

set pow to pow -0.02.

}.

if VERTICALSPEED < 199 {

set pow to pow +0.02.

}.

}.

What this code does is printing the speed and the altitude. And nothing else.

However if I remove the second if statement it works just fine. (Except that it may reduce the throttle a bit too much).

I dunno why.

edit: never mind just found out why.

Edited September 16, 2013 by Bizz Keryear

[Dunbaratu]

Actually maybe. I have romfarer installed with an extended view distance... couldn't help. Ill try a few things..

Exactly how is this done? I tried making a .txt file with that code I wrote in it, but it says not found when I try to run it in the game. How do I format this?

The key doesn't function. It simply adds a space. Semicolon works, but no colon.

And how does x,y,z reflect onto the navball? Because im thinking in terms of headings. 0 degrees North, 90 east, 180 south, 270 west. But if I understand what you explained to me that is the wrong way to go about it.

Supposedly support for thinking in those terms is planned for the future. But for now it works like this:

In the expression:

up * V(x,y,z).

The positive x direction is north, and the positive y direction is west, and the positive z direction is up.

So to translate compass points to X and Y you do this:

x = cos( compassPoint ) * cos(pitchUp)

y = sin( - compassPoint ) * cos(ptichUp)

z = sin( pitchUp )

(Where pitchUP = 0 on the horizion, 90 at the center of the blue part of the navball, and -90 at the center of the brown part of the navball.)

I haven't actually tried these numbers, mind you. This is just from guesswork in my head. Give it a try to make sure I've got the directions right. You may have to fiddle with the trig a bit if I got it wrong.

[KevinLaity]

And how does x,y,z reflect onto the navball? Because im thinking in terms of headings. 0 degrees North, 90 east, 180 south, 270 west. But if I understand what you explained to me that is the wrong way to go about it.

This is one of the big reasons I wanted a new way of steering, because a lot of people would like to navigate using the numbers on the navball as a reference.

0.6 is released with the new style of navigation now, see the release video for details.

LOCK STEERING TO HEADING 90 BY 40.   // 90 degree heading (east), 40 degrees above the horizon, just like on the navball

[Dunbaratu]

First thing 1st. I think it is a bit strange for a plugin created after 0.20 to use the old legacy directories.

Instead of <KSP directrory>/plugins it should be in <KSP directrory>/GameData/KOS/plugins

2nd: And somehow this plugin act strange at my side.

I have written this Program:

until altitude > 10000 {
print altitude at (0,1).
print VERTICALSPEED at (40,1).
if VERTICALSPEED > 210 { 
set pow to pow -0.02. 
}. 
if VERTICALSPEED < 199 { 
set pow to pow +0.02. 
}. 
}.

What this code does is printing the speed and the altitude. And nothing else.

However if I remove the second if statement it works just fine. (Except that it may reduce the throttle a bit too much).

I dunno why.

While I seriously love this mod, the fact that the script language is not being parsed in a properly recursive fashion becomes painfully clear at times and you may have run into one of those. Instead of every expression working the same way everywhere, each high-level construct defines its own syntax rules and they're not always the same. For example, one command might allow runs of 1 or more spaces between terms while others allow only exactly one space, and so on and so forth. OR as another problem I just ran into, the trig functions sin, cos, and tan don't allow parentheses inside themselves so you can't do sin( abs( a ) ) for example without doing it in two different statements.

[check]

This is one of the big reasons I wanted a new way of steering, because a lot of people would like to navigate using the numbers on the navball as a reference.

0.6 is released with the new style of navigation now, see the release video for details.

LOCK STEERING TO HEADING 90 BY 40.   // 90 degree heading (east), 40 degrees above the horizon, just like on the navball

Just watched the video. Lots of awesome new features! Thanks! My first immediate question is when you lock to a specific heading, how do you adjust the roll now to keep it locked at the new heading with the desired roll?

[KevinLaity]

Just watched the video. Lots of awesome new features! Thanks! My first immediate question is when you lock to a specific heading, how do you adjust the roll now to keep it locked at the new heading with the desired roll?

This will be implemented later on and will be an optional part of the same statement.

[Sma]

This is one of the big reasons I wanted a new way of steering, because a lot of people would like to navigate using the numbers on the navball as a reference.

0.6 is released with the new style of navigation now, see the release video for details.

LOCK STEERING TO HEADING 90 BY 40.   // 90 degree heading (east), 40 degrees above the horizon, just like on the navball

Awesome! Can't wait to try it out as soon as i get the game loaded up. I haven't done much with rovers, but I laughed when the rover was going in circles. . I tried getting to the video from here on the forums, then on your youtube page but it doesn't seem to be listed on either. I did find it on your blog though, so for others looking for the video check out Kevin's blog.

[Camacha]

- Preliminary support for 3rd party mod integration (Still testing)

Aw yeah! I like where this is going.

Also, I might be an idiot, but I can not seem to find the 0.6 release video in the TS, your Youtube channel or in the latter part of this thread. Am I overlooking something?

[Apollo13]

Would it be possible to make the device smaller and less obtrusive (perhaps flatter)? Or radial mounted, about the size of MechJeb.

[Dunbaratu]

Nice that the surface:vector is there. Feels like a waste of time that I went through the effort of finding it from the latitude and longitude, but it's better now that it's there.

Is there anything in the underlying mod API that lets you detect the existence of scatter rocks? If you have terrain scatter on, I think it would be a fun challenge to write a rover script that tries to head toward a destination location, BUT has to have the logic to stop and steer around rocks on the way. Right now there's no way to detect a rock without hitting it and noticing there's something preventing motion. Anyway, it's a good update. I like it.

[Kendrome]

I did some basic work on creating telnet server. There is still a lot of work todo as you can see with the glitch of the copy command being below everything else.

Kevin, if it is ok, how best would it be to contact you? I would like to be productive and help you out, you've done such an awesome job so far!

[JewelShisen]

Just watched the video. Lots of awesome new features! Thanks! My first immediate question is when you lock to a specific heading, how do you adjust the roll now to keep it locked at the new heading with the desired roll?

Umm... Where is the video?? I looked at his youtube at it is only up to 0.5

[drtedastro]

Rough group to play too.... Zero patience...... Take a breath, relax......

[Gaius]

Aw yeah! I like where this is going.

Also, I might be an idiot, but I can not seem to find the 0.6 release video in the TS, your Youtube channel or in the latter part of this thread. Am I overlooking something?

Yes, quite oddly, YouTube did not list it as a recent upload when searching on his username. However, it's linked from his devblog: http://kosdev.blogspot.ca/

[theSpeare]

I can't remember if this has already been answered but still no chance of Mechjeb functionality? It'd be great to be able to replicate what autom8 could do (and let's face it, that's never coming for another gazillion years) and also still work with a lot of kOS's nifty features at the same time.