kOS Scriptable Autopilot System 0.9

[Dunbaratu]

Ok, I have another issue. After docking two craft, I try to `lock steering to prograde.` at which point my craft just starts a roll then translates as fast as it can. I suspect the roll cannot keep up with the translate...

Is there *any* other way of setting my orientation *other* than using `lock steering` as `lock steering` does not operate well? All I want is to be able to roll x degrees or not roll depending on my whim, then steer my craft like normal, up down left and right the same way you always can. Not absolute directions, relative. It should be the most basic function of controlling your craft.

(is there a way to only adjust each value individually, so I could roll, then translate?)

I`m currently trying to lock steering for 1 seconds then sas on for 5 seconds to slow it down, then lock for two seconds again, rinse repeat.

this is not working. Every minute or so it ends up about 5 degrees closer to prograde with lots and lots of `not knowing which way to turn` inbetween...

Also is there a way to check your orientation is close to prograde so I can tell when to end this loop for example?

I refuse to accept that a ship design that rolls slower than it pitches is fundamentally uncontrollable. That would be terrible. This `you are forced to roll whenever you lock steering` is also very very frustrating.

At the core, is there any way to alter your attitude *without* doing a roll?

Mechjeb can control this craft perfectly FYI. It moves to the prograde marker and just sits there.

EDIT : After examining and forcing it to stop between letting it go for only a small amount of time it is actively heading *away* from prograde if it is near it. If I lock steering to up then it spins around the horizon and does nothing else and never settles down.

It's hard to tell from description alone what's going on. Can you post the code? I do get massive "turn the wrong way first" behavior from kOS, where it tends to sweep in a big curving arc that starts trying to go perpendicular to the desired direction instead of straight toward it, and then it realizes that's not the way it wants to go so it then curves back around and eventually gets to where I told it - but almost never in a straight simple turn. It's a bit annoying but it never really mattered that much except during ascent from large gravity wells. In other cases you can just make it wait and not fire the engines until the rotation is done, so you don't care how wonky the rotation was to get there. It's only during ascent that you can't do that because you need to leave the engines on as you do it. But then again, during ascent I'm never making big sweeping arc changes anyway as I'm trying to follow an ascent profile that starts off straight up and then very slowly curves off from that. (i.e. at one moment I've locked steering to a pitch of 45, then later to 44, then to 43, then to 42, etc. rather than going all the way from 45 to 0 all at once for example. I'm trying to make my ascent follow a path that looks roughly like the shape of a sideways parabola (a square root curve) so I sort of avoid the problem by the fact that making big changes all at once isn't appropriate to the algorithm I'm trying to do anyway. )

If you're in a position where you can just wait and drift until your steering stops going the wrong way, You can test whether or not it's lined up by comparing the Euler rotation called FACING to the one you've locked your steering to. FACING is the direction you are currently pointed, not the direction you are trying to point. So you wait until the difference between the pitch, yaw, and roll components of FACING are very close to those of your steering direction. (That check is a bit more ugly than it might seem because sometimes the rotations will be expressed in equivalent angles that look different if you just look at their raw numbers - i.e. -45 degrees as opposed to +315 degrees - So you have to do the trig on them to compare the angles (i.e. compare their sines and cosines.))

But in general I don't know why kOS doesn't steer in the most efficient direction toward the destination heading. i.e. if I was flying manually, and the angle I wanted to go to was about 45 degrees to the left of where I am pointing now, I'd just hold the "A" key down to start rotating to the left. But kOS seems to try to go UP first (i.e. the "S" key), then roll left (i.e. the "Q" key) until finally it has rolled over far enough that UP is now what LEFT used to be so it can pull up to go to the desired heading. That's a sort of silly way to it but at least if it's going to do that it should WAIT to pull up AFTER it's finished the rolling part so it can still draw a straight line across the navball to the new heading, not a big swooping arc. But at any rate I don't know why it didn't just yaw to the left instead.

There are times when I sort of wish I could just get independant control over what the keys do to simulate what the user is used to when flying the game manually: (That would also solve the RCS translation thing too - just let us do what the IJKLHN keys do and then let us work out the logic of how to make that work.)

[goldenpeach]

In case anyone missed the latest squadcast.... throttling engines independently confirmed for 0.23

I know that that's been requested feature for KOS players...

Will this allow to fire specific RCS thruster?

@ John FX and steven mading

When you say "prograde/retrograde" are you talking about your surface relative prograde(or retrograde) or your orbital one?

For 0.9, this plugin doesn't have a function for getting the surface relative prograde/retrograde; you have to code it yourself.

[deadshot462]

Just posting to say thanks to all those who provided answers to a lot of questions I searched this thread for.

And to the mod author, it's very challenging and rewarding to code your own crafts with this.

Looking forward to future updates.

[Camacha]

There are times when I sort of wish I could just get independant control over what the keys do to simulate what the user is used to when flying the game manually: (That would also solve the RCS translation thing too - just let us do what the IJKLHN keys do and then let us work out the logic of how to make that work.)

I kind of feel the same. Although lock steering (usually) makes life easy, it feels a little cheaty too. When it comes to the real thing, you will have to control these things seperately. Balance is a product of carefully tuning all controls, not something you just lock onto.

[Dunbaratu]

Will this allow to fire specific RCS thruster?

@ John FX and steven mading

When you say "prograde/retrograde" are you talking about your surface relative prograde(or retrograde) or your orbital one?

For 0.9, this plugin doesn't have a function for getting the surface relative prograde/retrograde; you have to code it yourself.

That's not true. Both are available, but just not in entirely the same format:

Say: LOCK STEERING TO _______

Where ______ is one of the things on the following table:

        \ Type
  Frame  \ of
   of     \ Data
 Reference \         Euler           XYZ
            \      Rotation         Vector
             |  R( __, __, __)    V( __, __, __)
    ---------+-----------------|-----------------------+
         pro |    PROGRADE     | VELOCITY:ORBIT        |
ORBITAL      |-----------------|-----------------------|
       retro |    RETROGRADE   | (-1)*VELOCITY:ORBIT   |
  -----------|-----------------|-----------------------|
         pro |  doesn't exist? | VELOCITY:SURFACE      |
SURFACE      |-----------------|-----------------------|
       retro |  doesn't exist? | (-1)*VELOCITY:SURFACE |
             +-----------------|-----------------------+

[John FX]

You might be wanting too much at once and doing it too abruptly. You could try finding out the difference between your current position and the one you want to be in and then ease into it. I did some testing which indicates that small steps prevent wild movements. Using larger increments or changing direction faster will lead to an increasing loss of control. You could even go the fancy route and have your script monitor the deviation. If that becomes too large, you slow down.

I assume you now that lock steering to (pitch, heading, roll) allows you to individually control each one?

Are you sure prograde remains the same direction all the time? Because if you use prograde or retrograde for something like landing, the directions will change if you are near standstill.

Prograde is the orbital one and it does not move as I have just entered the SOI of mun and I want to make a very simple and inefficient periapsis increaser that burns prograde for a little while.

I didn`t know about adjusting the attributes individually. Is that the `lock steering to heading(x,y,z).` command?

It's hard to tell from description alone what's going on. Can you post the code?

You can test whether or not it's lined up by comparing the Euler rotation called FACING to the one you've locked your steering to. FACING is the direction you are currently pointed, not the direction you are trying to point. So you wait until the difference between the pitch, yaw, and roll components of FACING are very close to those of your steering direction. (That check is a bit more ugly than it might seem because sometimes the rotations will be expressed in equivalent angles that look different if you just look at their raw numbers - i.e. -45 degrees as opposed to +315 degrees - So you have to do the trig on them to compare the angles (i.e. compare their sines and cosines.))

I`ll have a look at that also.

I think I`ll have to be a bit more mathematical than I planned at the start for this maneuver. I`m trying to do a mun mission with as little maths as possible. Everything is `thrust and look then stop or thrust more`. I`m not checking any formula generally and I`ve got to where I can launch to a 80120x79950 orbit, set up a FRT usually between 10-50km over Mun and burn and now I just need to face prograde.

My code is this

lock steering to prograde.
wait 30.

There is nothing special going on at all.

I think I may be fine double checking facing against the manual (pitch, heading, roll) and applying small adjustment to get facing=prograde (are the numbers in the same format?)

I`ll do three loops that adjust each value individually, slowly...

[Camacha]

I didn`t know about adjusting the attributes individually. Is that the `lock steering to heading(x,y,z).` command?

[...]

I think I may be fine double checking facing against the manual (pitch, heading, roll) and applying small adjustment to get facing=prograde (are the numbers in the same format?)

I`ll do three loops that adjust each value individually, slowly...

Yes, that's it. I am not sure you need to do them individually, as long as you take it slow.

[John FX]

Ok, is KOS really bugged or is it just me? I`m running this code now.

lock fr to facing:roll.
lock fp to facing:pitch.
lock fy to facing:yaw.
lock pr to prograde:roll.
lock tdiff to fr-pr.
until 0{
	print tdiff.
	set cr to fr+(tdiff/10).
	lock steering to heading(fp,fy,cr).
	wait 1.
	if abs(tdiff)<0.2 {break.}.
}.
print "rolled".

to try and simply roll by small amounts in the direction of prograde but all the time tdiff stays between -88.5 and -88.6 even when my craft spins wildly. I must be doing something wrong but I can`t see it. I`m trying to make one variable locked to my current roll, another to my desired roll and tdiff should be the difference. I divide that by 10 and try to turn in that direction by that amount then wait a short while and do it again.

Not the best solution but I hoped my roll value would change so I could see what was going on. It does not.

The same craft worked fine up until I staged and reconnected the lander.

I`ll try to just face the right way without rolling and see if that works.

EDIT: I cannot get my facing with facing. The numbers do not change. To the program I am not changing my pitch,yaw or roll so it throws the craft about trying to move.

I`ll try removing all mods except KOS and seeing if that works...

EDIT2: Still cannot see the roll value change. I can change pitch and yaw readings now though. I guess that would be enough. I am now suspecting a corrupted save. Making a fresh one to test...

Edited December 9, 2013 by John FX

[Camacha]

Ok, is KOS really bugged or is it just me? I`m running this code now.

Although kOS is far from perfect, I usually find that it is something stupid I did when things do not work as intended.

[John FX]

Although kOS is far from perfect, I usually find that it is something stupid I did when things do not work as intended.

Ok so I then ran

until 0{
clearscreen.
print prograde:roll.
print facing:roll.
wait 1.
}.

and turning/rolling by hand.

The roll values do not change. I do not expect the prograde:roll to change but when I am rolling my craft I do expect the facing:roll to change but it does not.

What am I doing wrong?

[Camacha]

Ok so I then ran

and turning/rolling by hand.

The roll values do not change. I do not expect the prograde:roll to change but when I am rolling my craft I do expect the facing:roll to change but it does not.

Yes, that is a bit strange. Luckily the roll value is least relevant (as your thrust will be the same direction, no matter the roll) and the yaw and pitch do work.

[John FX]

Yes, that is a bit strange. Luckily the roll value is least relevant (as your thrust will be the same direction, no matter the roll) and the yaw and pitch do work.

This is the workaround I have figured but it means I can`t use `lock steering to prograde.` which is frustrating. I have made a fresh save and relaunched to see if my save was corrupted.

EDIT : Ok, something weird is going on. I think my game install is corrupted. Now I can `lock steering to prograde` and all is fine so it`s not a KOS bug.

The only problem is the entire universe has vanished...

Black all around, even the map view. I`m going to try reloading and see if it is just a temporary glitch but I may just totally reinstall.

EDIT2: for some unknown reason everything is fine now. I can lock steering to prograde and retrograde. I do not know what could have gone wrong. I now have a craft doing a capture burn for mun without issues.

Edited December 9, 2013 by John FX

[Camacha]

I noticed that you might be confusing lock steering to heading and the readout you get in degrees. Those are not the same thing. The first works like the navball, the second is yaw in degrees and pitch in degrees.

Edited December 9, 2013 by Camacha

[Dunbaratu]

This is the workaround I have figured but it means I can`t use `lock steering to prograde.` which is frustrating. I have made a fresh save and relaunched to see if my save was corrupted.

EDIT : Ok, something weird is going on. I think my game install is corrupted. Now I can `lock steering to prograde` and all is fine so it`s not a KOS bug.

The only problem is the entire universe has vanished...

Black all around, even the map view. I`m going to try reloading and see if it is just a temporary glitch but I may just totally reinstall.

EDIT2: for some unknown reason everything is fine now. I can lock steering to prograde and retrograde. I do not know what could have gone wrong. I now have a craft doing a capture burn for mun without issues.

I have found that trying to use "revert flight" too many times with KOS enabled can do this (the black death effect). I've had success avoiding it by doing this:

Every time you're about to revert flight, FIRST go into the KOS terminal and give the command "SHUTDOWN.". THEN revert the flight.

There is something the KOS DLL is doing that leaves behind something still running when you revert flight. I'm not sure what it is, but a manual shutdown seems to avoid it.

[Camacha]

I have found that trying to use "revert flight" too many times with KOS enabled can do this (the black death effect).

I have to say I reverted a lot and did not see this behaviour. I have seen the other funky kOS stuff - ships partly loading (rare) or the interface going loopy (mostly when doing until loops) - but this I have not seen.

There might be a relevant difference between what I do and what you do when working on scripts.

[John FX]

I have found that trying to use "revert flight" too many times with KOS enabled can do this (the black death effect). I've had success avoiding it by doing this:

Every time you're about to revert flight, FIRST go into the KOS terminal and give the command "SHUTDOWN.". THEN revert the flight.

There is something the KOS DLL is doing that leaves behind something still running when you revert flight. I'm not sure what it is, but a manual shutdown seems to avoid it.

Aaaaah! This explains a lot. I`ll remember to shutdown the KOS terminal before I reboot the entire universe to avoid time loop paradoxes, hehe.

This may explain my original issue of failing to lock steering to prograde as I had been pressing F9 a lot just before...

Thank you very much guys. As it is, I am now orbiting mun between 10k and 30k and just need to circularise. I think without you I would not yet have launched...

I have to say I reverted a lot and did not see this behaviour. I have seen the other funky kOS stuff - ships partly loading (rare) or the interface going loopy (mostly when doing until loops) - but this I have not seen.

There might be a relevant difference between what I do and what you do when working on scripts.

Quite possibly. I also got partly loaded ship corruption a few quickloads after the ship failed to turn. I`ve had my staging vanish along with the kerbals in the ship and the entire universe has vanished.

As the problems have fixed themselves with a new save I`m guessing that was the culprit

Edited December 9, 2013 by John FX

[Dunbaratu]

Ok, is KOS really bugged or is it just me? I`m running this code now.

lock fr to facing:roll.
lock fp to facing:pitch.
lock fy to facing:yaw.
lock pr to prograde:roll.
lock tdiff to fr-pr.
until 0{
	print tdiff.
	set cr to fr+(tdiff/10).
	lock steering to heading(fp,fy,cr).
	wait 1.
	if abs(tdiff)<0.2 {break.}.
}.
print "rolled".

to try and simply roll by small amounts in the direction of prograde but all the time tdiff stays between -88.5 and -88.6 even when my craft spins wildly.

I think that HEADING(__,__,__) is not the same as a Euler rotation like R(__,__,__). The values of FACING and PROGRADE are given in Euler rotations "R(__,__,__) but then you're setting them using HEADING(__,__,__) which isn't the same coordinate system.

All Directions in KOS by default get converted into Euler Rotations when you read them back out even if you didn't set them that way, which can be a bit annoying at times. You can SET your steering by HEADING(_,_,_) or V(_,_,_) but you can't READ it back that way. It always reads back out as R(_,_,_) regardless of how you set it.

The difference is that HEADING conforms to the navball, while R(_,_,_) is giving your rotation from the super-secret invisible XYZ system that KSP uses internally, which can be a very confusing challenge to understand, as it's not consistent from one minute to the next. (Basically, when you are high above the planet, the planet rotates around Y and the universe stays put, but when you're close in to the planet, it freezes and instead the universe rotates around Y. Depending on exactly when you transitioned between those states, the X and Z axes could be aligned with any arbitrary longitude and the only thing you know for sure is that they're 90 degrees off from each other. The Z axis might be north one moment and then a half hour later in the same game it's now southeast because it rotated for a while and then re-froze.

So HEADING gives you a nice navball-centric coordinate system to use, but then when you READ your values back, they're not expressed in that system. They're back to telling you how far you're rotated from wherever the heck the X and Z axes happen to be at the moment.

[sarkun]

Hi guys, does anyone have a good (meaning fast) natural logarithm script lying around?

[Camacha]

Hi guys, does anyone have a good (meaning fast) natural logarithm script lying around?

Maybe Sensor Reporter could be of use

math!log(number) - returns the base-10 logarithm of the given number.

math!logb(number, base) - returns the logarithm of the given number of the given base.

math!ln(number) - returns the natural logarithm of the given number.

math!e() - returns the natural log base constant e.

[Dunbaratu]

Maybe Sensor Reporter could be of use

I wish I'd known that existed before I went and wrote this in my script:

  set gTurnPres to 0.25 . // Atmospheres of pressure where I want to start my gravity turn.

  // Calculating the altitude at which air pressure is 0.25 ATM's, using that
  // as an altitude at which to go into the turn.
  print "".
  print "Calculating a natural log by series....".
  print "Please be patient".
  print "".
  // trying to do this:
  //     set gTurnBot to -ln (0.25/(atmToPres*bodtAtmSea))*bodyAtmScale.
  set x to (gTurnPres/(atmToPres*bodyAtmSea)).
  set lnSoFar to 0.
  set n to 1.
  // KOS 0.92 has no logarithm functions so I'm using a series.
  // lnSoFar approaches ln(x) as the series converges:
  until n >= 30 {
    set lnSoFar to lnSoFar + (  ( (0-1)^(n+1) / n )*( (x-1)^n )  ).
    set n to n + 1.
  }.
  set gTurnBot to (0-lnSoFar)*bodyAtmScale.

It seems like it might be a good idea to move those math functions in to the main kOS code, since they're not technically part of sensor functionality, but are a bit more low-level than that.

[Camacha]

I wish I'd known that existed before I went and wrote this in my script:

It seems like it might be a good idea to move those math functions in to the main kOS code, since they're not technically part of sensor functionality, but are a bit more low-level than that.

If it were up to me Sensor Reporter got integrated into kOS - that way the expressions will fit seemlessly instead of having to be the kind of odd additions they are now - but I can imagine that Woodywood wants to keep his work discrete. I volunteered the idea a little while ago, but there was no response.

[check]

So Kevin seems to have fallen off the face of the Earth.... what's the deal? Anyone know?

[Camacha]

So Kevin seems to have fallen off the face of the Earth.... what's the deal? Anyone know?

A couple of days ago Bizz Keryear managed to contact him. The message was that he had some personal stuff to deal with.

[check]

A couple of days ago Bizz Keryear managed to contact him. The message was that he had some personal stuff to deal with.

Ah. Cool, thanks.

[woodywood245]

If it were up to me Sensor Reporter got integrated into kOS - that way the expressions will fit seemlessly instead of having to be the kind of odd additions they are now - but I can imagine that Woodywood wants to keep his work discrete. I volunteered the idea a little while ago, but there was no response.

There are a lot of things I've written that I'd love to see integrated directly into kOS (most of it being in the kOSExtensions portion of Sensor Reporter), and a few ideas I can't implement without changing the kOS source, but with Kevin away for a while, and final exams coming up, I haven't had an opportunity or urge to get in contact with him to see what we can do. Also, I've noticed that a lot of the code that gets written into the code base by people other than Kevin never see the light of day during release. Someone wrote the original Sensor Reporter code into the code base a while back (it wasn't me, and no one asked me), but it hasn't appeared in any releases.