Jump to content

kOS Scriptable Autopilot System 0.9


KevinLaity

Recommended Posts

So I have this idea in my head and I want to see what you all think. I want to create an autopilot for my SSTO shuttle. The ascent part isn't too tricky once I stop making sloppy coding errors. Landing is a bit more difficult. The current plan I have in my head is to set up a series of probe markers all in a straight line leading through the runway. There would be one at the end of the runway, one at the beginning, and then a few more out to the west of the runway. As the ship approached each marker, it would change targets to the next and continue it's descent. Does that sound like a fair way of doing it or am I missing something very simple in the coding language that would accomplish the same goal without the markers?

Link to comment
Share on other sites

No it doesn't. It's identical to a program with the comments and whitespace stripped which is far smaller. Most of that 7k is legibility not algorithm (and some of it is just the fact that it was written before KOS had some of the features it has now. Like the extra PRINT lines to redraw the menu all over the place is because PRINT AT didn't exist yet when it was first started.[...]
That wasn't the point.

The point was that they should

a. add more computers if the current space isn't enough.

b. consider if they want to write a to the vessel personalized version of a program instead of a coping "ready to use with fancy menus" solution.

I'm editing in an external gvim window. I've already got this feeling by setting the colors the way I want and downloading a C64 font to use in the editor.

I was not speaking of the editor! I meant the in-game command line and output screen. ... of course it would also affect this last-minute-final-edit editor.

(expl: I have stoped running programs from archive, and copy them before the start. like it was intended)

Link to comment
Share on other sites

That wasn't the point.

The point was that they should

a. add more computers if the current space isn't enough.

b. consider if they want to write a to the vessel personalized version of a program instead of a coping "ready to use with fancy menus" solution.

I was not speaking of the editor! I meant the in-game command line and output screen. ... of course it would also affect this last-minute-final-edit editor.

(expl: I have stoped running programs from archive, and copy them before the start. like it was intended)

I don't have to run them from the archive either just because I edit them in a real editor that isn't crippled. My kerbals write the software at home and then transmit it to the craft. Nobody in their right mind would write the software by typing across a remote terminal connection to a terminal server halfway across the solar system when they could write it at home on the ground and transmit the final result to the craft, the way it was intended.

And when doing it that way, you don't bother sending comments to the craft. The comments are for the benefit of the human - the computer doesn't care about them.

Link to comment
Share on other sites

Sorry to keep bugging you guys but I've spent a few hours trying to figure this out and I've come up with nothing. I want my space plane to take off from the runway with a 20 degree angle of attack heading west. I tried lock steering to up + r(0,-70,0). as well as every other possible number for the roll component and it refuses to take off. I also tried just R(0,20,0) as well as several others. Am I missing something hear? Couldn't quite figure out heading either.

I'm sure this has been asked before but all my searching through the thread and I couldn't find it. Sorry! It is 100 pages long after all. =)

Link to comment
Share on other sites

Sorry to keep bugging you guys but I've spent a few hours trying to figure this out and I've come up with nothing. I want my space plane to take off from the runway with a 20 degree angle of attack heading west. I tried lock steering to up + r(0,-70,0). as well as every other possible number for the roll component and it refuses to take off. I also tried just R(0,20,0) as well as several others. Am I missing something hear? Couldn't quite figure out heading either.

I'm sure this has been asked before but all my searching through the thread and I couldn't find it. Sorry! It is 100 pages long after all. =)

You want to go West right?


lock steering to heading 270 by 20.

Usage: lock steering to heading [b]X[/b] by [b]pitch[/b].

Not sure what that is going to do with the roll.

You may need to use the harder method.

An example of that is in this post.

http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-65?p=650207&viewfull=1#post650207

That example doesn't include roll but it isn't that hard to add.

Link to comment
Share on other sites

You want to go West right?


lock steering to heading 270 by 20.

Usage: lock steering to heading [b]X[/b] by [b]pitch[/b].

Not sure what that is going to do with the roll.

You may need to use the harder method.

An example of that is in this post.

http://forum.kerbalspaceprogram.com/threads/47399-kOS-Scriptable-Autopilot-System-0-65?p=650207&viewfull=1#post650207

That example doesn't include roll but it isn't that hard to add.

Silly me typing west. I meant east but that should just be 90. I will give that a try again but it was giving me an awful lot of trouble before. I'll give the harder method a try as well.

Link to comment
Share on other sites

Made a new video for my latest kOS script--- a cruise missile!

Can hit a target up to 250 km away and is able to hug the terrain at 500m if over mountains and even lover over flatter routes.

that's cool!! If we could get integration with laser systems you could maybe use that to adjust the pitch to compensate for whats coming in the terrain, like a forward looking radar thing? I dont't know but sounds cool. lol :)

Link to comment
Share on other sites

Made a new video for my latest kOS script--- a cruise missile!

Can hit a target up to 250 km away and is able to hug the terrain at 500m if over mountains and even lover over flatter routes.

Enjoy.

Wow! Very well done!

I'd like to feature this video on the kOS dev blog, please let me know if that's cool with you.

Link to comment
Share on other sites

can someone please give me an update on how steering is supposed to work for rockets? I had it working fine in 0.5 but afterwards it doesn't seem to work. If I try the new by heading that also doesn't seem to work. Should this "lock steering to heading 90 by 90." not make the rocket point straight up and face east?

Link to comment
Share on other sites

I don't have to run them from the archive either just because I edit them in a real editor that isn't crippled. My kerbals write the software at home and then transmit it to the craft. Nobody in their right mind would write the software by typing across a remote terminal connection to a terminal server halfway across the solar system when they could write it at home on the ground and transmit the final result to the craft, the way it was intended.

And when doing it that way, you don't bother sending comments to the craft. The comments are for the benefit of the human - the computer doesn't care about them.

Jeb would do that. (I am pretty sure about that)With a long cable from to of the rocket while lying under engine...
can someone please give me an update on how steering is supposed to work for rockets? I had it working fine in 0.5 but afterwards it doesn't seem to work. If I try the new by heading that also doesn't seem to work. Should this "lock steering to heading 90 by 90." not make the rocket point straight up and face east?

Look at the compass the

lock steering to heading XX by YY.

is exactly what is written there, but your craft will roll. Unfortunately the roll is (was?) broken. Since I was busy updating the wiki I haven't that tested yet. Anyway if roll is working then the command is

lock steering to heading XX by YY +R(0,0,180).

. But if roll is still broken your craft will point in a random direction with that code. So better use it without.

edit lock steering to heading 90 by 90 is basicly UP. facing east and up

Link to comment
Share on other sites

So I have this idea in my head and I want to see what you all think. I want to create an autopilot for my SSTO shuttle. The ascent part isn't too tricky once I stop making sloppy coding errors. Landing is a bit more difficult. The current plan I have in my head is to set up a series of probe markers all in a straight line leading through the runway. There would be one at the end of the runway, one at the beginning, and then a few more out to the west of the runway. As the ship approached each marker, it would change targets to the next and continue it's descent. Does that sound like a fair way of doing it or am I missing something very simple in the coding language that would accomplish the same goal without the markers?

Have you gotten this sorted out yet, at least partially? I don't know much about targeting my self, so far all I've done is launch a rocket and circularize with my code. I would imagine you could do it two ways...one with how you mentioned using markers (although I would think you could get by with just 2, one at each end of the runway. If you 're coming in from the east you'd target one of them, making sure to be at a specific speed/altitude within a certain distance of the target then adjust your pitch a certain number of degrees accordingly. You COULD possibly get away with 1 in the middle of the runway, but you would run the risk of colliding with it.

Another option would be to use the lat/long of the landing strip. For that you could, I would imagine, query the lat/long before you take off, save them in some variables, then when it comes time to land maneuver to those coordinates. Sounds easier than it really is though I'm sure. :wink: I guess using the targets at the ends of the runway (maybe not actually on the runway) would be easier though. Could even be as simple as the small probe core with an rtg on the side, lowest profile as possible so as to not stick up over the runway burm, could even name them according to the number on the runway.

Link to comment
Share on other sites

People have had problems with the fact that the steering acts all wonky for a while before it settles down on the chosen heading the first time you activate it. The craft needs to spin a bit around all 3 axes before it "learns" its controls, it seems. The problem is how to have the code wait for that initial wonky steer period to finish before doing anything else like turning on engines, when the waiting period has to be tailor-made to each craft since they don't all rotate at the same rate. Well, now that someone clued me in to the undocumented "FACING" property that's in the Mod's code, I have the better solution to the problem, shown below:


// Assume mySteer is an R() tuple of some sort.
// You could replace "mySteer" with "Up" or "North"
// or any other canonical direction.
lock steering to mySteer.

// Wait until the aim has lined up before continuing:
set align to 90. // anything bigger than 5 will do.
until align < 5 {
set pDiff to facing:pitch - mySteer:pitch.
set yDiff to facing:yaw - mySteer:yaw.
set align to abs(pDiff) + abs(yDiff).
}.
// Now do other stuff like activate the engine.

I originally tried this by just putting the entire expression together into one statement like so:


wait until
( abs(facing:yaw-mySteer:yaw) + abs(facing:pitch-mySteer:pitch) ) < 5 .

But the notoriously wonky KOS parser couldn't understand that so I had to separate it into separate statements like you see above.

Link to comment
Share on other sites

lately (since 0.65) I have the problem that, while a program in kOS is running, becomes "kinda" slow.

I mean it runs fine with good framerate then stops completely for about half a second. Then continues for a random time and stops again. and so on.

If I stop the running program everything is fine.

I also have to, each time I use the kOS computer after creating a new craft, switch the power off and on. Otherwise, while the kOS seems ok, at the first command I run it freezes. Well turning it off and on also fixes that.

The latest program I was running:

clearscreen.
set head to 270.
set pich to 2.
lock steering to heading head by pich.
set flag to 0.
until 0 {
set a to ALT:RADAR.
print a at (0,15).
print "heading " at (0,16).
print head + " " at (8,16).
print " by pitch " at (0,17).
print pich + " " at (12,17).

on ag4 set flag to 1.
on ag5 set flag to 2.
on ag6 set flag to 3.
on ag7 set flag to 4.
if flag = 1 {
set pich to pich + 1.
set flag to 0.
}.
if flag = 2 {
set pich to pich - 1.
set flag to 0.
}.
if flag = 3 {
set head to head + 5.
if head > 360 {
set head to head - 360.
}.
set flag to 0.
}.
if flag = 4 {
set head to head - 5.
if head < 0 {
set head to 360 + head.
}.
set flag to 0.
}.
}.

had also problems. According to the videos on ag<1-10> {do_some_stuff.}. should be conform. but if I actual use it it does nothing. You can see my workaround above.

Also from time to time the plane pulled up or steered in wired directions... Even when no key was touched.

I have the feeling after 0.5 it becomes buggier and buggier...

Link to comment
Share on other sites

Yes I noticed the new update does make my KSP chug a lot. I can tell you one thing for sure, you need to get out of the habit of using until 0. In lots of computing languages, that is a way that programmers use to leave comments in code. It depends on the compiler, but it generally means ignore the following.

Set a variable called Done or whatever to 0 and then..... until Done = 1 { Do these things. }.

Link to comment
Share on other sites

When did "log to" become a thing? Was just watching ep2 of the journey to the ~~north pole~~ south pole and he was talking about this. I guess I must have missed it some how. Dunno what I'd use it for just yet, but I'll have to play around with it and figure something out.

Link to comment
Share on other sites

So, is vector math known to be broken? I was expecting "lock x to facing - prograde" to give me a vector that I could then reason about to determine whether or not I'm at the attitude I locked in, but I get back values which don't wrap correctly, e.g. R(1,361,724). As other posts in this thread seem to confirm, this makes it very hard to reason about any kind of orientation in space.

Or am I just doing something wrong?

Link to comment
Share on other sites

So, is vector math known to be broken? I was expecting "lock x to facing - prograde" to give me a vector that I could then reason about to determine whether or not I'm at the attitude I locked in, but I get back values which don't wrap correctly, e.g. R(1,361,724). As other posts in this thread seem to confirm, this makes it very hard to reason about any kind of orientation in space.

Or am I just doing something wrong?

Nope. It's totally weird. kOS looks at KSP's native coordinate system which are totally not intuitive.

Link to comment
Share on other sites

So, is vector math known to be broken? I was expecting "lock x to facing - prograde" to give me a vector that I could then reason about to determine whether or not I'm at the attitude I locked in, but I get back values which don't wrap correctly, e.g. R(1,361,724). As other posts in this thread seem to confirm, this makes it very hard to reason about any kind of orientation in space.

Or am I just doing something wrong?

Vector math is broken because the system keeps trying to cast all vectors into Directions. (A Direction only mentions rotation angles, not magnitude).

The only way I've been able to use vectors correctly is to manually do all the vector math myself by getting the vector components by:

set vec to prograde.

vec:x

vec:y

vec:z

Then you can add vectors by adding their components, or perform matrix math on them or dot products and so on. But you have to do it all yourself. You can't even just do a simple scalar magnitude multiplication like:

halfspeed = 0.5 * prograde.

There's a lot of underlying vector operations in the underlying C# api that we don't have access to.

Link to comment
Share on other sites

Nope. It's totally weird. kOS looks at KSP's native coordinate system which are totally not intuitive.

And we're missing most of the information we could use to actually work out what the native system is. We can learn our velocity in the native system, but not the position.

I wasted a lot of hours of detective work to figure out if there is any way to find the underlying system from what little data IS available and I got this sort of worked out:

http://kos.wikia.com/wiki/Tutorial_-_KOS_0.61_and_above:_Finding_surface_dynamic_information

Link to comment
Share on other sites

wheels just do not steer at all.

Does anyone know why this doesn't work?

1 - Land a rover on the Mun. It has an SCS on it.

2 - Make sure brakes are off.

3 - Open SCS terminal window.

4 - type command "lock wheelthrottle to 0.3". Rover starts moving slowly in a straight line. Good.

5 - type command "lock wheelsteering to 60." No change. Keeps going in straight line.

6 - type command "lock wheelsteering to 210." No change. Keeps going in the same straight line.

7 - type command "lock steering to heading 210 by 0." No change. Keeps going in the same straight line.

NOTHING makes the wheels turn. Why?

Link to comment
Share on other sites

Is there a way to lock to target?


clearscreen.

print "Locking to Target.".

LOCK STEERING TO TARGET.

until 0 { wait 1. }.

?

I made a missile that I want to hit a probe with. Its a spent third stage that missed the Mun. I figure if I can lock onto the target with kOS and have an engine setup that can continually burn I can get an impact.

Edited by Motokid600
Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...