[1.3] kOS Scriptable Autopilot System v1.1.3.0

[GabeTeuton]

While that can be a problem, in this case even if that wasn't happening it's STILL a bad idea for @GabeTeuton to be checking for exactly zero. Because even without the artificial artifact of computer floating point precision problems, in the *real* world you're not going to get the system that accurate.

Gabe, imagine this: you work as a general errand runner and gopher in a chemistry lab where your boss has said, "I'm cooling this down until it's 30 degrees, then we can start. Your instructions are to look at this digital thermometer and tell me when it says the temperature is exactly 30 degrees." You say "okay, will do!"

Then you look at it and it says 35.21301.. then 34.2411... then 32.21623.. then 31.01835, then 30.51821, then 30.201262, then 30.013011, then 30.003151, then 30.000045, then 30.00010, then 29.99912, then 29.999941. then 30.00004, then 29.999910. then 30.00004, then 30.000012, then 29.99919.... etc.

At what point should you say "okay that's close enough to 30 degrees that it counts? It's clearly unable to hold it at exactly 30 to more than about 0.001 accuracy."?

This is the problem with what you're doing. Even in the real world an autopilot cannot possibly get the climb rate as accurate as you're looking for here. It will inevitibly waver a bit above and below the desired number. Your job is to ensure that it wavers around that point by as small a margin as possible, not to do the impossible and make it stick to it so precisely that it's accurate up to 12 significant digits. That's utterly impossible.

(currently i'm away from my computer so development stopped until tomorrow morning/afternoon)... I see your point, once again I'm kind of amazed with what you present me, in a good way of course... (this way of thinking about it evaded me until now) So based on your thoughts and the fact that there is no workaround to such a true fact, i guess i will abandon this iteration and go back to the previous one, to try and make it wobble less, first i'll try to replicate the first iteration, in which the user had to adjust the value, i'll start by making that more precise, and then jump to the other iteration, the one that kind of automatically "maintained" altitude with a small margin of error, and try to make that margin even smaller i was also suggested by a pm to make a PID controller instead of what i'm trying to do, i'll check what that has to offer aswell...

thanks guys!

[Dunbaratu]

(currently i'm away from my computer so development stopped until tomorrow morning/afternoon)... I see your point, once again I'm kind of amazed with what you present me, in a good way of course... (this way of thinking about it evaded me until now) So based on your thoughts and the fact that there is no workaround to such a true fact, i guess i will abandon this iteration and go back to the previous one, to try and make it wobble less, first i'll try to replicate the first iteration, in which the user had to adjust the value, i'll start by making that more precise, and then jump to the other iteration, the one that kind of automatically "maintained" altitude with a small margin of error, and try to make that margin even smaller i was also suggested by a pm to make a PID controller instead of what i'm trying to do, i'll check what that has to offer aswell...

The general case solution is start by thinking this way:

"The amount by which I choose to push the controls to move toward my target number should depend on how far off I am from my target number." If you are near the desired number, push less. If you are far away from it, push more.

That, is basically a P controller - positional only. In your case it would mean "push more the farther from the programmed altitude I am".

Then if that's not good enough then you add current velocity to the calculation. "The amount by which I choose to push the controls to move toward my target number should depend on BOTH how far off I am AND my current velocity toward the desired number." (my current climb rate). It depends on both current altitude AND the difference between current altitude and previous altitude (vertical speed).

Then if THAT's not good enough, then you take the derivative of THAT and keep trying again, now take into account Position (altitude), AND Velocity (vertical velocity), AND Accelleration (change to vertical velocity), and so on.

It's how you keep dampening the oscillations more and more given that your computer isn't capable of doing its work with perfect instantaneous response.

And that, in a nutshell, is what a PID controller is trying to do, although the fact that this is what it's trying to do is a bit hidden behind some confusing math terminology, but in a nutshell, it's what I described above. To control phenomenon X, remember the previous few measurements of X and you can get a crude approximation of the deltas of that phenomenon over the previous timestep, and therefore a crude approximation of the current derivatives of the phenomenon. For example the derivative, the approximate change in X over the last timestep is ((Current X minus previous X) / delta time ). You can get the change in the change in X (second derivative) by remembering the previously calculated first derivative and compare how IT changed in that delta time. Of course, the accuracy of these goes up the shorter the delta time is.

By using all this information together you can help make a much smoother control of your ship that wobbles and oscillates less.

[GabeTeuton]

The general case solution is start by thinking this way:

"The amount by which I choose to push the controls to move toward my target number should depend on how far off I am from my target number." If you are near the desired number, push less. If you are far away from it, push more.

That, is basically a P controller - positional only. In your case it would mean "push more the farther from the programmed altitude I am".

Then if that's not good enough then you add current velocity to the calculation. "The amount by which I choose to push the controls to move toward my target number should depend on BOTH how far off I am AND my current velocity toward the desired number." (my current climb rate). It depends on both current altitude AND the difference between current altitude and previous altitude (vertical speed).

Then if THAT's not good enough, then you take the derivative of THAT and keep trying again, now take into account Position (altitude), AND Velocity (vertical velocity), AND Accelleration (change to vertical velocity), and so on.

It's how you keep dampening the oscillations more and more given that your computer isn't capable of doing its work with perfect instantaneous response.

And that, in a nutshell, is what a PID controller is trying to do, although the fact that this is what it's trying to do is a bit hidden behind some confusing math terminology, but in a nutshell, it's what I described above. To control phenomenon X, remember the previous few measurements of X and you can get a crude approximation of the deltas of that phenomenon over the previous timestep, and therefore a crude approximation of the current derivatives of the phenomenon. For example the derivative, the approximate change in X over the last timestep is ((Current X minus previous X) / delta time ). You can get the change in the change in X (second derivative) by remembering the previously calculated first derivative and compare how IT changed in that delta time. Of course, the accuracy of these goes up the shorter the delta time is.

By using all this information together you can help make a much smoother control of your ship that wobbles and oscillates less.

I always liked math, used to love the derivatives calculation, numerical integration, of course after years without practising it, (and the fact that i'm kind of away from my degree [i mean i'm not attending to university as usually as i should], as well as the fact that my career is not that related with hard math, being business management), i'm kind of rusty in that matter... but till today those calculations still amaze and amuse me... And what you say once again is logical...

One question i wanted to ask since a long time ago, and didn't ask, is=

can i set a condition for a number to be in between 2 numbers? like

this is just an example of what i mean, not sure if it works and currently i can't test it, but i read on the docs that AND and OR is a possibility, though i didn't find much in terms of its usage...

SET P TO 0.
IF P < 500 AND P > 400 THEN { PRINT "P IS MORE THAN 400 AND LESS THAN 500" AT (0,0).
UNTIL P = 1000 { SET P TO P + 1. WAIT 5. }.

I believe if this is possible i can narrow down the wobbling by setting a margin for both below and above of desired altitude, using also what you just added in the quoted comment to change the step size the closer you are to the target.

[Dunbaratu]

AND and OR work exactly as you expect. You can chain together any long number of conditions like that.

The only thing to remember is that when there's a chain of AND and OR conditions, the default is to assume all the ANDs happen before all the ORs. (AND is analagous to multiplication and OR is analagous to addition, in the sense that 1+4*5 means "do 4*5 first, then do +1 to that", just like A OR B AND C means "do B and C first, then 'OR' that with A".)

You can always override this with explicit parentheses, like so: (A OR AND C

The reason for this nomenclature comes from the original concept of Boolean algebra, which preceeds the invention of computers by quite a bit. (Boolean algebra was published in 1847 as just a quirky way to mathematically express the language of logic. It was mostly ignored as just an interesting mathematical footnote until the invention of computers revived it to being quite useful.)

In Boolean algebra, you express the concept of "true" with "any number that isn't zero" (usually '1' but it doesn't have to be) and you express the concept of "false" with zero.

Then the rules of logic end up mapping exactly one-to-one with rules of algebra in a nice clean way when you do this, which is why the idea got a big boost when computers arrived, as it provided a way to map statements of logic into mathematical operations a computer can do.

[Dunbaratu]

IMO, for working with numbers within an epsilon tolerance it occurs to me that it would be a very useful shorthand for kOS to supply people with a function that works like so:

if WITHIN( x, 5.0, 0.1) { stuff }.

Which means "is x nearly 5.0, within a tolerance of plus or minus 0.1?", and would be the same as this:

if x >= (5.0-0.1) and x <= (5.0+0.1) { stuff }.

[GabeTeuton]

IMO, for working with numbers within an epsilon tolerance it occurs to me that it would be a very useful shorthand for kOS to supply people with a function that works like so:

if WITHIN( x, 5.0, 0.1) { stuff }.

Which means "is x nearly 5.0, within a tolerance of plus or minus 0.1?", and would be the same as this:

if x >= (5.0-0.1) and x <= (5.0+0.1) { stuff }.

I agree, good idea. Though this addition shouldn't remove the option of doing it both ways.-

[Cairan]

One word: deadband.

What you are describing with a tolerance margin is what we call a deadband, a zone where no further corrections are made but we keep an eye on the error trend.. if delta-error increases, it means you are starting to drift out ofyour deadband...

[Dunbaratu]

One word: deadband.

What you are describing with a tolerance margin is what we call a deadband, a zone where no further corrections are made but we keep an eye on the error trend.. if delta-error increases, it means you are starting to drift out ofyour deadband...

But that's waay too specific of a term that only applies to one use of it. I'm just referring to the very generic test of "is X within plus or minus Y of Z?", which can be done with ANDed conditions but it gets wordy and ugly after a bit and it's such a commonly needed operation that it makes sense to make it a function. It's a bit like MIN or MAX. It's trivially easy to write code that does the same thing with an if condition, but it gets wordy and makes the visual flow more clunky than just having a shorthand function for it.

[Camacha]

That might be useful for mitigating noise in PID-controllers.

[Lorentz]

IMO, for working with numbers within an epsilon tolerance it occurs to me that it would be a very useful shorthand for kOS to supply people with a function that works like so:

if WITHIN( x, 5.0, 0.1) { stuff }.

Which means "is x nearly 5.0, within a tolerance of plus or minus 0.1?", and would be the same as this:

if x >= (5.0-0.1) and x <= (5.0+0.1) { stuff }.

I prefer this (pythonic) way if possible:

IF 4.9 < x < 5.1 { stuff. }

However, its pretty easy just to do this:

IF ABS(x - 5.0) < 0.1 { stuff. }

[Hitokiri]

Hi, anyone have idea why LOCK STEERING TO Heading (90,20) in atmosphere cause that roll control is oscillating?

[erendrake]

Hi, anyone have idea why LOCK STEERING TO Heading (90,20) in atmosphere cause that roll control is oscillating?

The design of LOCK STEERING is to be a very basic algorithm that will get you more or less in the right direction. If you want finer control you can always use the raw controls

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

[Hitokiri]

The design of LOCK STEERING is to be a very basic algorithm that will get you more or less in the right direction. If you want finer control you can always use the raw controls

http://ksp-kos.github.io/KOS_DOC/summary_topics/ship_control/index.html

Well, I read the most of documentation for KOS on github and my "feeling" was that "cooked" control was somehow preferred. (well the article about control starts with them, right?)

Is there any tutorial how to use raw control? For example I can see that both Mechjeb and "cooked" control in KOS will actually keep pitch to 1.0 in order to fly desired 20° in high atmosphere supersonic flight (1300m/s @ 20k). So I assume that I have to write some subroutine that will actually change the Pitch inflight to keep desired heading...

[Cairan]

I prefer this (pythonic) way if possible:

IF 4.9 < x < 5.1 { stuff. }

However, its pretty easy just to do this:

IF ABS(x - 5.0) < 0.1 { stuff. }

Albeit I do most of my paid-for coding in Python nowadays, I have to look at the overall feel of kOS syntax, I prefer the second implementation...

While we are discussing new instructions (WITHIN), I'd like to request a TIMER/SLEEP function in kOS... Most probes nowadays include a deep-sleep mode in which only the RTC and a couple of keepalive circuits are powered, and the rest of the probe is powered off... Most surface probes to Mars, Titan's Huygens, Pluto's New Horizons, are programmed with a timer which wakes up just before critical events are to be handled. No triggers (ON, WAIT, etc.) would be enabled during such a deep sleep mode.

Say I launch a probe to Duna but I don't want to consume any power from a fuel cell on my way there:

UNTIL ENCOUNTER:NAME = "Duna" {
... // Probe stuff goes here before we get in the cruise phase...
}
SLEEP ETA:TRANSITION. // Basically SHUTDOWN but with a restore of operation when we transition to another SOI...
RUN LanderProg. // Here we run the lander script much later only when we get in the SOI of Duna...

Another use would be to save power during the Munar night:

WHEN SunElev < 0 { // When the sun sets below the horizon... Could very well be based on power drain threshold instead...
  LOCK WHEELTHROTTLE TO 0. 
  SAS OFF.
  LIGHTS OFF.
  BRAKES ON.
  // ...other power saving actions here... ie. action groups triggers to shutdown instruments, etc.
  SLEEP 69492. // Half of Mun's rotation period, ie. from sunset to sunrise... the kOS CPU will resume the script when it wakes up at that time...
  SAS ON.
  LIGHTS ON.
  BRAKES OFF.
  // ... actions to resume science, processing, other operations...
  PRESERVE.
}.

Just to emphasize before I log off, this is not the same as the existing WAIT instruction. It is an hybrid of WAIT with SHUTDOWN... The power consumption of the kOS CPU could be set to 0 or some very small value while in the SLEEP mode. Both the Apollo AGC and the STS GPCs had such power saving CPU instructions.

Edited November 5, 2014 by Cairan

[Trewor007]

How can i check the current phase angle? There is tons of info how to calculate it for a transfer, but nothing about my current kerbin-duna phase angle.

[Dunbaratu]

How can i check the current phase angle? There is tons of info how to calculate it for a transfer, but nothing about my current kerbin-duna phase angle.

You can get the following 3 positions in space:

Kerbin:Position

Sun:Position

Duna:Position

Now you've got 3 points in space you can use to form the angle, and calculate it.

[madlemur]

You can get the following 3 positions in space:

Kerbin:Position

Sun:Position

Duna:Position

Now you've got 3 points in space you can use to form the angle, and calculate it.

Hmmm... If we could just write our own functions...

Edited November 5, 2014 by madlemur

[Trewor007]

Steven Mading thanks! that was way more easy than my method, now my code is 50% time correct (and that's 49% increasement in accuracy). now I just need to figure out, a condition to tell apart when duna is behind and when in front of me.

Hmmm... If we could just write our own functions...

Who needs functions when we have vectors

Edited November 5, 2014 by Trewor007

[SnappingTurtle]

Couple questions.

Is there a command to quit a script?

Is there a way to get the position of a part?

And is there a way to tell what type the selected target is?

Also a sign function for the math lib would be nice

Edited November 5, 2014 by SnappingTurtle

[Dunbaratu]

Steven Mading thanks! that was way more easy than my method, now my code is 50% time correct (and that's 49% increasement in accuracy). now I just need to figure out, a condition to tell apart when duna is behind and when in front of me.

A normal vector of Kerbin's orbit plane:

set posKerbinFromSun to (kerbin:position - sun:position).
set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit).
set normKerbinOrbit to VCRS( velKerbinFromSun, posKerbinFromSun ).

A cross product of the position vectors kerbin-to-sun and kerbin-to-duna:

set posDunaFromKerbin to (duna:position - kerbin:position).
set crossSunKerbinDuna to VCRS( (-1)*posKerbinFromSun, posDunaFromKerbin ).

If Duna is ahead of Kerbin, the direction of the two cross products should be mostly the same.

If Duna is behind Kerbin, the direction of the two cross products should be mostly opposed.

set crossesAngle to VANG(normKerbinOrbit,crossSunKerbinDuna).
if cos(crossesAngle) > 0 {
  print "test: Duna is ahead of Kerbin".
} else {
  print "test: Duna is behind Kerbin".
}.

I am doing this by picturing the vectors in my head and not testing it, so I might have the signs flipped. Give it a try. It should either be 100% right or 100% backward.

Edited November 5, 2014 by Steven Mading

[Dunbaratu]

Couple questions.

Is there a command to quit a script?

No. There should be. It's sort of tied into how we'll eventually do functions though, and the relationship between an "exit" and a "return" should probably be established, and of course does "exit" just quit the current RUN SCRIPTNAME or does it kill all the way to the interactive prompt?

Is there a way to get the position of a part?

Yes .... but see here: https://github.com/KSP-KOS/KOS/issues/277

And is there a way to tell what type the selected target is?

IMO all objects should be able to print their KOS type. They curently can't because they aren't all wrapped inside a suffix-able type. Hmm... changing that would be a really good idea for the future.

[Trewor007]

Is there a command to quit a script?

Yes there is.

Is there a way to get the position of a part?

that depends.

And is there a way to tell what type the selected target is?

Good question, not very specific but good.

If U R using a loop just use "break." if not use REBOOT or SHUTDOWN.

if it comes just to the facing of the part: http://ksp-kos.github.io/KOS_DOC/structure/part/index.html but if U want its position in the ship than probably no. (i have no idea really).

kos has hard coded names of the planets so its kinda see the difference between planet and a ship. however difference between a rover and a probe is, a no no.

[SnappingTurtle]

Thanks for the replies. I'm trying to write a script to dock with a target. Is this something that would have to wait for future updates?

Also is there a ternary operator like in C?

Edited November 5, 2014 by SnappingTurtle

[Dunbaratu]

Thanks for the replies. I'm trying to write a script to dock with a target. Is this something that would have to wait for future updates?

It's doable now, but the problem is that there isn't a good way to SET TARGET TO the docking port, just the vessel in general. So as long as your target docking port is aligned with the vessel's center of mass, you can sort of do it. But if it's offcenter it's a bit harder.

The big problem you'll encounter is that if you have the docking port in a variable, the position it returns to you is currently unusable because of this: https://github.com/KSP-KOS/KOS/issues/277

I did have some success with a docking script, but it has to assume the target's docking port is aligned to its center of mass for now.

Also is there a ternary operator like in C?

Do you mean "X = cond ? val1 : val2" ? Not currently. It would be possible, though, if there's enough interest in it.

[Trewor007]

SnappingTurtle Ive remember seeing on youtube docking with KOS. So You can try. a ternary operator? Nope ( but not 100% sure).

Steven Mading

I donk know why but my KOS is protesting at this line;/

set velKerbinFromSun to (kerbin:velocity:orbit - sun:velocity:orbit).

Its probably a glitch on my ksp side (I've used :velocity:orbit literally yesterday).

I've done it, a little bit different ( read as: its more code, and its a mess.), in relation to sun position the plane is divided in 4 squares and im checking in witch one is kerbin and duna at one time. that's a lot of combinations but its working for now.