kOS Scriptable Autopilot System 0.9

[Sacred Aardvark]

Quick question: how does kOS know anything is a variable? The examples use X and Y, but I notice that I often have to use something like alttime1 instead of alttime for kOS to understand what I mean.

Only times I've had issues with variables, was when I had "someexessivelylongdescriptivevariablename", and the other was when I was using "alt" as a variable(fixed by changing to "alti"), probably because it's also used for "alt:radar" and such. Your example has "alt" and "time", both of which can be called in other situations, so maybe the parser gets confused there.

I'm purely guessing here, it might have nothing to do with what I just said.

[kalizec]

No, but lots of people have the same problem, and the more that report it the better. I thought it was just me, but clearly it's not. Something is broken about going on-rails and then coming back off-rails again, which also uses the persistence file and has the same symptoms.

alright, have loaded 2 savegames with "kOS" parts on my ships. Each one was corrupt, with half the ship missing.

snip

https://github.com/Nivekk/KOS/issues/220

[Sacred Aardvark]

I'll see if running the ascent script prior to the deorbit changes anything, when I wake up (unless someone figures it out )

Good morning, gave it a go and after running your ascent script to get into orbit, I was able to run the deorbit script without an error.

http://i.imgur.com/ZgGhYuH.jpg

If that mystical invisible arrow thingy isn't the culprit, the problem could be one of your other mods, since the scripts work. (at least in the sense that they run and don't produce errors, deorb could use more delay between steering to retro and starting burn )

You are using the latest version, yes? 0.92, with the display glitch of showing version 0.91 in the console?

[ttnarg]

FYI retrograde is always based on your obital speeds.

but you can do:

r(180,0,0)+velocity:surface.

here is the start of a powered lander scripted I'm working on.

print "start landing".
set mythrust to 0.
lock throttle to mythrust.
until (alt:radar < 5)
{
  lock steering to r(180,0,0)+velocity:surface.

  set speedlimit to alt:radar/10.

  set test to velocity:surface:mag.
  set test to test - 5.
  set test to test/speedlimit.

  if (test>1)
  {
    set test to 1.
  }
  if (test<0)
  {
    set test to 0.
  }
  set mythrust to test.
  print mythrust.

}.
print "done".
set mythrust to 0.
wait 1.
unlock throttle.
unlock steering.

[Sma]

The up-arrow is the Commodore 64's font set way of printing the caret character, and the game borrows a Commodore 64 font so I guess this is what's happening.

(I sort of wish it had the full Commodore 64 font set so I could draw boxes and lines with it, but it doesn't have those characters.)

I didn't even think about that...that would be awesome.

[whistlehead]

It's probably been asked before - but does this work with remotetech 2? If so, does it work alongside it but based on its own rules, or does it work with those laid down by remotetech?

Thanks,

Chris

[Sacred Aardvark]

It's probably been asked before - but does this work with remotetech 2? If so, does it work alongside it but based on its own rules, or does it work with those laid down by remotetech?

Thanks,

Chris

I was going to say that there is an update to RT coming "at the end of the week", but it seems to have been released pretty much -now-, though it seems to require some patched dll. See RT-thread for details. haven't had the chance to do a proper read through it yet myself.

kOS integration:

All immediate mode actions now require signal delay to pass;

Steering locks now work when the vessel is disconnected;

Action groups no longer trigger when kOS has them blocked;

"BATCH" and "DEPLOY" commands to send a list of commands as one packet;

Requires patched kOS DLL until I merge the changes. Download here.

http://forum.kerbalspaceprogram.com/threads/56399-0-22-RemoteTech-2-v1-1-0-November-7-Build-those-satellite-networks!?p=781796&viewfull=1#post781796

Edited November 15, 2013 by Sacred Aardvark
it's not me, my keyboard is making the typos

[whistlehead]

Posted since I asked the question, even! Thanks for the heads-up.

[Dunbaratu]

We all know that when you first tell KOS to change steering it tends to spin around stupidly for a bit first in completely the wrong direction before it realizes which way to turn and fixes itself. This is giving me a lot of trouble during my ascent script because when I tell it to go from a pitch of 90 degrees down to a pitch of 70 degrees in the east direction, it always first aims north for a bit and then curves around to east. by the time it does that it's already imparted enough delta-v in the northward direction that it will cause my final orbit to have a bit of inclination when I didn't want it.

In the past I could always get around this by shutting the engines off until facing matched the desired direction, and THEN burn. But I hadn't made a launch script yet. That method works great in space, but not when launching. When launching you don't want to shut the engines off for the 10-15 seconds or so it takes for KOS to find out which way is which, because you need that precious momentum.

[ANWRocketMan]

As great as this mod is, there's one thing that I would really like to be able to do before I start using it for my realism savegame.

I'm using the real size mod with a lot of other realism-related edits I've done myself. Namely I disabled reaction wheels on all parts, except if specifically added through the reaction wheel/SAS systems. Now, in addition, RCS is not nearly as plentiful as it usually is as I now have oxygen and CO2 to add into each pod as well. I also use RemoteTech 2(will be anyway) for proper remote controlled craft. The problem with this is the massive delay times involved in this is too much to manually control my probes. Now, here's the function I would like to be able to write:

When you want to turn to a specific orientation, instead of having the craft jump around and spin and waste tons of RCS fuel, I want to be able to do a small RCS burn in a specific direction, then let the probe coast until the correct pitch/yaw or roll is reached. At that point or just before, the script burns a tiny mount of RCS in the opposite direction to stop the movement. It might be needed to do a small timewarp to fully stop the turning at this point, though.

Is there a way to do this now? Or should I start modding and playing Orbiter instead?(never tried it)

[Sma]

We all know that when you first tell KOS to change steering it tends to spin around stupidly for a bit first in completely the wrong direction before it realizes which way to turn and fixes itself. This is giving me a lot of trouble during my ascent script because when I tell it to go from a pitch of 90 degrees down to a pitch of 70 degrees in the east direction, it always first aims north for a bit and then curves around to east. by the time it does that it's already imparted enough delta-v in the northward direction that it will cause my final orbit to have a bit of inclination when I didn't want it.

In the past I could always get around this by shutting the engines off until facing matched the desired direction, and THEN burn. But I hadn't made a launch script yet. That method works great in space, but not when launching. When launching you don't want to shut the engines off for the 10-15 seconds or so it takes for KOS to find out which way is which, because you need that precious momentum.

I use "heading by" most of the time and what I'm doing in my script is first I turn on SAS, launch, wait for maybe 10 seconds, then going to 90 by 90. Example:

sas on.
lock throttle to 1.
stage.
wait 10.
lock steering to heading 90 by 90.
sas off.
wait until altitude > 10000.
lock steering to heading 90 by 45.
...

It's a simple example but I think you get it. What happens here is it does the rotation to whatever roll its doing while straight up, so it doesnt change the flight path. Then when the pitch over occures its already in the orientation it's expecting. Does the trick for me most of the time.

[Sma]

As great as this mod is, there's one thing that I would really like to be able to do before I start using it for my realism savegame.

I'm using the real size mod with a lot of other realism-related edits I've done myself. Namely I disabled reaction wheels on all parts, except if specifically added through the reaction wheel/SAS systems. Now, in addition, RCS is not nearly as plentiful as it usually is as I now have oxygen and CO2 to add into each pod as well. I also use RemoteTech 2(will be anyway) for proper remote controlled craft. The problem with this is the massive delay times involved in this is too much to manually control my probes. Now, here's the function I would like to be able to write:

When you want to turn to a specific orientation, instead of having the craft jump around and spin and waste tons of RCS fuel, I want to be able to do a small RCS burn in a specific direction, then let the probe coast until the correct pitch/yaw or roll is reached. At that point or just before, the script burns a tiny mount of RCS in the opposite direction to stop the movement. It might be needed to do a small timewarp to fully stop the turning at this point, though.

Is there a way to do this now? Or should I start modding and playing Orbiter instead?(never tried it)

I haven't tried using rcs with kOS but, you could program in tiny heading adjustments, or whatever method you are using.

lock steering to up + R(0,10,0).
wait 5.
lock steering to up + R(0,15,0).
....
//or
set x to 0.
while x < 100 {
set p1 to p1 + 0.1.
set x to x+1.
lock steering to up + r(0,p1,0).

Although I guess that doesn't really work for heading to a target/node though. The next best thing then I guess would be to use fine control, although I imagine that's still too fast. Hmmm....

[Sacred Aardvark]

We all know that when you first tell KOS to change steering it tends to spin around stupidly for a bit first in completely the wrong direction before it realizes which way to turn and fixes itself. This is giving me a lot of trouble during my ascent script because when I tell it to go from a pitch of 90 degrees down to a pitch of 70 degrees in the east direction, it always first aims north for a bit and then curves around to east. by the time it does that it's already imparted enough delta-v in the northward direction that it will cause my final orbit to have a bit of inclination when I didn't want it.

Are you accounting for roll? From the launchpad, pitch input will correlate to north-south, you'll need to do a 90 degree roll to get pitch control aligned with east-west, doing the pitch and roll at the same time tends to result in the type of behaviour you described. I start from the pad with "heading 90 by 90." (well, x by y, but whatever), which causes the ship to roll it's navball belly to east immediately on takeoff, after which changing to "90 by 45" or whatever pitches directly east, without passing north or collecting 200$.

YMMW if you're using the other methods of guiding direction.

TBH that behaviour drives me bonkers in MechJeb (which does it too in it's SASS), but I don't really notice it in kOS, I tend to account for it in the programs, whereas with MJ it catches me off guard

Or I could have completely misunderstood your problem and spent the last few minutes rambling about something irrelevant

[edit] Sma beat me to it.

Edited November 15, 2013 by Sacred Aardvark
Hi Jim, I'd like to buy a line break

[Camacha]

In the past I could always get around this by shutting the engines off until facing matched the desired direction, and THEN burn. But I hadn't made a launch script yet. That method works great in space, but not when launching. When launching you don't want to shut the engines off for the 10-15 seconds or so it takes for KOS to find out which way is which, because you need that precious momentum.

I helps to ease into it. I do not have a lot of experience with ascent scripts either as I only started working with kOS yesterday, but as a test I built a small script that rotates per degree instead of 20 degrees at once. It works perfectly for a small rocket.

Of course the mechanisms in the script are crude and not what you want for a proper and efficient ascent, but the ride is smooth enough. No wild shaking at all.

lock throttle to (1).
set pitch1 to 90.
lock steering to heading 90 by pitch1.
print "Go!".
stage.
wait 10.

until pitch1 < 0 {
    set pitch1 to pitch1 - 0.1.
    print pitch1.
    wait 0.1.
}.

unlock steering.

Edited November 16, 2013 by Camacha

[Dunbaratu]

I use "heading by" most of the time and what I'm doing in my script is first I turn on SAS, launch, wait for maybe 10 seconds, then going to 90 by 90. Example:

sas on.
lock throttle to 1.
stage.
wait 10.
lock steering to heading 90 by 90.
sas off.
wait until altitude > 10000.
lock steering to heading 90 by 45.
...

It's a simple example but I think you get it. What happens here is it does the rotation to whatever roll its doing while straight up, so it doesnt change the flight path. Then when the pitch over occures its already in the orientation it's expecting. Does the trick for me most of the time.

I can't see the relevant difference between that and what I'm doing, which is this:

// "steering" is already locked to "mysteer" by this point in the script.
lock mypitch to 90. 
lock mycompass to (90 - endIncl).
lock mysteer to HEADING mycompass BY mypitch.

And then later on when I get to the altitude I'd like to begin my gravity turn, I do this:

when altitude > gTurnBot then {
  // Steer it based on a cheezy parabola path (which isn't exactly right
  // for a gravity turn but the true answer requires ugly differential
  // equations and integration by slices, so screw it.)
  // The closer to the final desired velocity, the closer to horizontal to steer:
  lock mypitch to (90 - ( sqrt( (usevel:mag) / endSpd ) * 90 ) ).
}.

So it flies at HEADING 90 by 90 until it hits the height I want to start the turn at, and then it leaves the compass part alone and changes pitch to follow that sqare-root path. And the moment it does it turns NORTH instead of east, and then after about 10-15 seconds finally has corrected itself to east.

If I'm going about 220 m/s when the turn starts, it typically ends up rotating down to about pitch 64 or so at that point. (The exact pitch changes depending on how fast I'm going.

EDIT: oooooookayyyy.. I just ran my program a second time without changing ANY of that code at all, and now it works fine. I'm wondering if I had some leftover lock of some type that only cleared when I quit and restarted KOS?

Edited November 15, 2013 by Steven Mading

[NathanKell]

ANWRocketMan I second your request (for obvious reasons )

It shouldn't be hard to write a controller for that. Compute delta-pitch and delta-yaw to desired heading; make a small rcs burn in the correct ratio; wait for (near) correct heading and make the killrot burn.

[BrickedKeyboard]

Like any programming language, you can emulate this feature with a lot of code. You could set the steering to just a few degrees over to activate the RCS, then a moment later, release the steering, and have you script calculate the rate of change (the angular turn rate). You could keep doing this, "steering" ahead of where you want to be, and doing the opposite to slow down at the other end.

[Camacha]

I am already seeing some use for the sensors I mentioned before. It would be very nice it rovers would able to see something ahead. I just dispatched two rescue rovers to a mishap as a test, but they ran into each other at the target. Not very useful

Some basic range finding equipment or SONAR or LIDAR would be very nice.

I am also slowly but surely getting my head wrapped around the lack of formal loops and labels/pointers. It takes some getting used to, but kOS seems to have a basic but adequate command list. The intended accessible language seems a succes to me.

I use "heading by" most of the time [...] What happens here is it does the rotation to whatever roll its doing while straight up, so it doesnt change the flight path. Then when the pitch over occures its already in the orientation it's expecting. Does the trick for me most of the time.

You know you can use lock steering to heading (direction, pitch, rotation), right? This enables you to prevent unwanted rolls, as craft are sometimes rotated on the landing pad at launch.

Edited November 16, 2013 by Camacha

[Sma]

You know you can use lock steering to heading (direction, pitch, rotation), right? This enables you to prevent unwanted rolls, as craft are sometimes rotated on the landing pad at launch.

I use to use

lock steering to up + r(0,45,90)

or something like that I forget exactly how i used it but lately have just been using ...heading 90 by 90. How would you use it in the way you mentioned? For the most part though I don't really have an issue with what I'm doing now, though I could maybe see it being a problem if im flying a plane or something else.

[dimmy]

How can i set up autonavigate to the vessel in front of me (in 1km ahead)?

[dimmy]

How to enumerate all ships in my solar system and select which is near 1km to me?

[Dunbaratu]

How to enumerate all ships in my solar system and select which is near 1km to me?

While you can list things with a command like this:

LIST TARGETS.

The list only shows up on the terminal screen and there's no way to capture it into a variable (yet?). I suppose a prerequisite for getting that data into variables would be support for arrays, which KOSscript doesn't have (yet?). (You'd need to store the result in something you could iterate over (thing 1, thing 2, thing 3, etc) and that would have to mean arrays or lists or something like that.

[dimmy]

so its another useless mod without ability "move to nearest ship"

in multiplayer (kmp) itll be great

[Sacred Aardvark]

so its another useless mod without ability "move to nearest ship"

I think you're looking for MechJeb. Though even for that I think you'll need to figure out yourself what the closest ship is.

I can't even think of a reason why one would want to "move to the nearest ship", since I'd think usually you would want to be moving to a specific ship, not just a random one that's near, even if that specific ship happens to be the nearest ship. But my inability to see a situation where it would be useful is a fault of mine and not yours.

And yes, you can code kOS to move towards a specific ship. (I have an outline of the code in my head, but haven't actually tried doing it yet)

If you're looking for an easy, out of the box autopilot, I recommend MechJeb. If you're looking for tools to code an autopilot yourself you're in the right place, but it will take some effort to design the programs and get them working. The wiki, readme and to some extent the introductory videos are good places to start.

[dimmy]

If you're looking for an easy, out of the box autopilot, I recommend MechJeb. If you're looking for tools to code an autopilot yourself you're in the right place, but it will take some effort to design the programs and get them working. The wiki, readme and to some extent the introductory videos are good places to start.

for this i should enumerate ships.

list ships gets them, how to enumerate?

for (i = 0; i< ships.count(); i++)

if ( distanceTo(ship) < 1000) {

moveHeadTo(ship);

openDocks();

break;

}

i was reading readme and faq.

and find all without enumeration ("for" cycle)

there is " until " cycle, but how can i select SHIP[0].NAME , SHIP[1].NAME ?

how can i get SHIP.SIZE() ?

i find my ships by name of them, for example.