kOS Scriptable Autopilot System 0.9

[Dunbaratu]

For those who don't believe me:

I started from the first image, then burned slowly to the second image while printing my apoapsis as I burned. Note it stopped giving me negative numbers *before* I was captured. Therefore the thing that began the entire bug report, that being the fact that the numbers do NOT in fact tell me if I'm going to escape or not, is true.

Addendum: checking for STATUS="ESCAPING" has the same problem. It will claim I've been captured (STATUS="ORBITING") when in fact I haven't been. It's reporting numbers as if KSP's concept of an SOI radius didn't exist.

If you want to roll back the changes to re-instate this behavior, then please explain an alternate way to get this data. I don't know how to query the game for the body's SOI radius. If there was a way to do that, that could provide an alternate way to get this information (if apoapsis < 0 or apoapsis > Mun:SOI would work for example, if there was such a thing in the language as Mun:SOI).

Edited November 27, 2013 by Steven Mading

[Dunbaratu]

On another front, I've found a much easier way to work-around the craft loading bug.

Before you leave a craft that you intend to come back to later, issue this command on the KOS part (or all the KOS parts) that ever ran any KOS code:

SHUTDOWN.

Then when you reload the craft you can turn the KOS unit back on from the toggle power option on the rightclick menu..

The fact that the craft was shut off when it went onto rails means the KOS mod didn't try to save its variable context in the persistence file.

[KvickFlygarn87]

Where is Kevin Laity? This could need some attention, with updates and such.

[mordieth]

It seems that the Infernal Robotics way of intercepting keypresses messes with the normal action groups. However, if you set the action groups in the editor (move - to ag1 and move + to ag2) it is possible to use them through kOS.

ag1 off.
ag2 off.
ag9 off.

until ag9 = "True" {
  if ag1 = "True" {wait 2. ag1 off.}.
  if ag2 = "True" {wait 2. ag2 off.}.
}.

Downside when using this method is that the timing in kOS is not highly accurate, so when you press 4 and 5 a number of times, the neutral position might be different than the starting position. The same goes for when your hinge meets an end stop. Until we get real IR support that is how it is.

Sorry if i'm being dense here but, for me that code doesn't do anything for me except complete when i press the key for ag9. am i missing something?

[Dunbaratu]

I keep having this happen in my script and I can't figure out why. It just started happening recently. When the script gets to the part where it hits "stage" the first time, it completely ruins KSP, doing THIS to it:

(Note the weird values for altitude and velocity. Most properties I attempt to print after the entire scree blacks out like that end up being bogus NaN values. They weren't prior to the blackout.)

The only recourse at this point is to kill KSP from the task manager.

As near as I can tell this happens as soon as I execute "stage". I'm still trying to trace down the conditions that cause it. Every time I try making a reduced version of the ascent program that removes everything except the problem lines, it runs fine.

[KvickFlygarn87]

I keep having this happen in my script and I can't figure out why. It just started happening recently. When the script gets to the part where it hits "stage" the first time, it completely ruins KSP, doing THIS to it:

(Note the weird values for altitude and velocity. Most properties I attempt to print after the entire scree blacks out like that end up being bogus NaN values. They weren't prior to the blackout.)

The only recourse at this point is to kill KSP from the task manager.

As near as I can tell this happens as soon as I execute "stage". I'm still trying to trace down the conditions that cause it. Every time I try making a reduced version of the ascent program that removes everything except the problem lines, it runs fine.

Good morning, Hell Kraken!

[Dunbaratu]

Good morning, Hell Kraken!

Apparently the expression I was trying to lock the throttle to was producing a value of Infinity while maxthrust was zero, which it temporarily is for just an instant during the staging process. So I unlock the throttle, then do the stage, then relock the throttle and the problem seems to have gone away.

[Garek]

So if you throttle to infinity, the Hell Kraken eats you? seems kind of appropriate Oo

[Sacred Aardvark]

So if you throttle to infinity, the Hell Kraken eats you? seems kind of appropriate Oo

"To Infinity... and beyond!"

[wingnut]

Could someone please review a script for me which is supposed to calculate true anomaly in an eccentric orbit and after that the altitude and speed at this true anomaly.

The script seems to deliver results which are not completely wrong but I can't verify that the calculated true anomaly is correct. Further to this, the calculated altitude and speed always seem to be corresponding to the periapsis even when I enter different mean anomalies.

My script is based on the algorithm found on http://www.jgiesen.de/kepler/kepler.html as well as the equations and example problems of the Orbital Mechanics page on http://www.braeunig.us/space/.

This is the script:

// True anomaly
set mu to 3.5316000*10^12.  // gravitational parameter
set rb to 600000.           // radius of body
declare parameter tof.
set a to (rb*2 + periapsis + apoapsis)/2. //SMa
set ec to ((rb+apoapsis) - (rb+periapsis))/((rb+apoapsis) + (rb+periapsis)). //eccentricity
set t to 2*3.14159*sqrt(a^3/mu). //orbital period
set n to sqrt(mu/a^3). //mean motion
set M to n * tof. //mean anomaly at tof seconds after periapsis

set maxiter to 30.
set delta to 10^-3.
set i to 0.

if ec < 0.8 {set E to m.} //eccentric anomaly
if ec >= 0.8 {set E to 3.14159.}

set F to E - ec * sin(m) - m.
set absF to F.
if absF < 0 {set absF to F * (-1).}

until absF <= delta OR i < maxiter {
	set E to E - F / (1.0 - ec * cos(E)).
	set F to E - ec * sin(E) - m.
	set absF to F.
	if absF < 0 {set absF to F * (-1).}
	set i to i + 1.
}

//set E to E / (3.14159 / 180). // convert to degree

set fak to sqrt(1.0 - ec^2).
set phi to arctan2(fak * sin(E), cos(E) - ec).

set r to a * (1 - ec^2) / (1 + ec * cos(phi)). // altitude at true anomaly
set v to sqrt(mu * (2 / r - 1 / a)). // velocity at true anomaly

print "Elements for " + multi + " seconds after periapsis".
log "Elements for " + multi + " seconds after periapsis" to orblog.
print "True anomaly: " + phi.
log "True anomaly: " + phi to orblog.
print "Mean anomaly: " + M.
log "Mean anomaly: " + M to orblog.
print "Eccentric anomaly: " + E.
log "Eccentric anomaly: " + E to orblog.
print "Radius: " + r.
log "Radius: " + r to orblog.
print "Speed: " + v.
log "Speed: " + v to orblog.

This is output created by the script for a ca. 80km x 1,000 km Kerbin orbit:

Elements for 3037.5 seconds after periapsis
True anomaly: 5.77998497874809
Mean anomaly: 3.14123160679727
Eccentric anomaly: 3.14123160679727
Radius: 679672.744713293
Speed: 2832.04616886257

Elements for 0 seconds after periapsis
True anomaly: 0
Mean anomaly: 0
Eccentric anomaly: 0
Radius: 678454.711152033
Speed: 2835.3381463772

Elements for 1518.75 seconds after periapsis
True anomaly: 2.89128867366892
Mean anomaly: 1.57061583805724
Eccentric anomaly: 1.57061583805724
Radius: 678759.294063534
Speed: 2834.51419835746

Edited November 28, 2013 by wingnut

[Bizz Keryear]

Where is Kevin Laity? This could need some attention, with updates and such.

Funny you ask... He made me become an internet stalker of him ... Last sign of life: (I found so far) 17 hours ago ... source: *secret* ... Bad enough that I stalk.

Edit: frighting how public live has become ... now I know things about him I never wanted to know...

Edited November 28, 2013 by Bizz Keryear

[AbeS]

@wingnut, why don't you just: set r to rb + altitude ? it's easier

[asdfCYBER]

This is absolutely a fantastic mod! I always wanted something like this!

[wingnut]

@wingnut, why don't you just: set r to rb + altitude ? it's easier

Because you need the True Anomaly to calculate your altitude and speed at any point in the orbit in contrast to Altitude and velocity:orbit:mag only returning the current values.

I think the discrepancies may have something to do with the way Sin and Cos are calculated but I'm not sure. I've setup virtually the same script in a Java class and I get accurate results there...

[AbeS]

Oh I get it! I've always wanted such a script!

[Camacha]

If you want to roll back the changes to re-instate this behavior, then please explain an alternate way to get this data. I don't know how to query the game for the body's SOI radius. If there was a way to do that, that could provide an alternate way to get this information (if apoapsis < 0 or apoapsis > Mun:SOI would work for example, if there was such a thing in the language as Mun:SOI).

I feel this is a different matter. If a number is useful, it should not be removed from the code. If that causes other problems they should be solved in their own way.

Sorry if i'm being dense here but, for me that code doesn't do anything for me except complete when i press the key for ag9. am i missing something?

Did you set the actions groups in the editor/VAB for the Infernal Robotics part you are trying to control? After adding the part to your construction, set move - to ag1 and move + to ag2. Note, this is something different than setting the keys in the Infernal Robotics pop-up.

Without an Infernal Robotics part or setting the correct action groups in the VAB for that part not much will happen

Edited November 28, 2013 by Camacha

[baloan]

I started from the first image, then burned slowly to the second image while printing my apoapsis as I burned. Note it stopped giving me negative numbers *before* I was captured. Therefore the thing that began the entire bug report, that being the fact that the numbers do NOT in fact tell me if I'm going to escape or not, is true.

Addendum: checking for STATUS="ESCAPING" has the same problem. It will claim I've been captured (STATUS="ORBITING") when in fact I haven't been. It's reporting numbers as if KSP's concept of an SOI radius didn't exist.

Hi Steven,

Works as designed.

One thing in advance. We have

1. orbital energy which is invariant and does only change when burning the engine (or thrusters),

2. how KSP approximates the laws of gravity. It uses patched conics. This is were SOI comes from

and 1. and 2. are two different things.

When we look at apoapsis we look at 1. To better understand what happens we also look at specific orbital energy soe.

soe is defined like this:

a) negative while captured (elliptic)

0 for parabolic escape

c) positive for hyperbolic escape

soe = - mu / sma // sma being the semi-major axis

sma = (rper + 2*rmun + rapo)/2 // with periapsis, the bodies' radius and apoapsis, respectively.

When you burn prograde you add energy to soe, retrograde you remove energy.

How to explain the apoapsis values?

On the picture it looks like your starting orbit was probably circular, i.e. periapsis ~230km as well. I use that number - and rmun = 200km - to compute soe.

apoapsis: 229198, soe ~ -60000 (using mu for Mun with 6E+10)

Now you have burned prograde, added lots of energy and produced a hyperbolic escape trajectory. soe has become positive.

apoapsis: -1722155, soe ~ 1022155 (hyperbolic escape)

How much energy you added to soe? Calculate for yourself: deltasoe = (v2^2 - v1^2)/2

As long as you don't burn here, no energy added or removed, soe remains constant and apoapsis doesn't change (have you checked?)

Here you have started burning retrograde, removing energy, soe gets smaller, sma and apoapsis greater.

apoapsis: -4018355

apoapsis: -5677602

apoapsis: -79147548

until soe crosses 0 and becomes negative, apoapsis starts to come down from infinity.

apoapsis: +3312767, soe < 0 again

apoapsis: +2342288

Once your apoapsis becomes smaller than soi KSP will show you a closed orbit.

Geometrically apoapsis flip to the opposite side of the opening of the hyperbola. That and due to the maths it becomes negative.

The vertex at the end of the blue line is the soi. It is due to KSP's approach on how to deal with gravity that the soi differs from the physics of an escape orbit. periapsis, apoapsis, velocity:orbit:mag, altitude are all about the potential and kinetic energy in the system.

So why is soi so different from the energy escape orbit?

The soi radius is used in KSP to simplify calculating gravitation. Within the soi only the body inside pulls at your ship (simple to calculate two body problem). All others planets, moon like Kerbin or the Sun are ignored. This is grossly wrong but good enough for the game and good enough for estimating transfers in reality. The soi is the boundary where Mun and Kerbin's gravitational force are equal. At the soi - in reality - your vessel will not move, in the game it falls to one of the bodies. That is why the game does not have Lagrange points.

Essentially that is why physics and the soi vertex on the blue trajectory line do not match.

Actually the guys who coded KSP obviously used the physical properties to determine status and not the soi.

For getting the soi (or the radius) of a body you need to build a database - or better: we make those constants available in kOS.

Btw: I agree with Camacha on: as a rule in a software system you should not change existing variables because it will break existing code. Instead add a new one. (Unless there is a very good reason to change it...)

Edited November 28, 2013 by baloan

[baloan]

Could someone please review a script

Double check the loop variables.

[baloan]

On another front, I've found a much easier way to work-around the craft loading bug.

Before you leave a craft that you intend to come back to later, issue this command on the KOS part (or all the KOS parts) that ever ran any KOS code:

SHUTDOWN.

That's a nice workaround. I'll try that next time.

Should be fixed next time we get a release nonetheless.

[Dunbaratu]

Hi Steven,

Works as designed.

One thing in advance. We have

1. orbital energy which is invariant and does only change when burning the engine (or thrusters),

2. how KSP approximates the laws of gravity. It uses patched conics. This is were SOI comes from

and 1. and 2. are two different things.

When we look at apoapsis we look at 1. To better understand what happens we also look at specific orbital energy soe.

soe is defined like this:

a) negative while captured (elliptic)

0 for parabolic escape

c) positive for hyperbolic escape

soe = - mu / sma // sma being the semi-major axis

sma = (rper + 2*rmun + rapo)/2 // with periapsis, the bodies' radius and apoapsis, respectively.

When you burn prograde you add energy to soe, retrograde you remove energy.

How to explain the apoapsis values?

On the picture it looks like your starting orbit was probably circular, i.e. periapsis ~230km as well. I use that number - and rmun = 200km - to compute soe.

apoapsis: 229198, soe ~ -60000 (using mu for Mun with 6E+10)

Now you have burned prograde, added lots of energy and produced a hyperbolic escape trajectory. soe has become positive.

apoapsis: -1722155, soe ~ 1022155 (hyperbolic escape)

How much energy you added to soe? Calculate for yourself: deltasoe = (v2^2 - v1^2)/2

As long as you don't burn here, no energy added or removed, soe remains constant and apoapsis doesn't change (have you checked?)

Here you have started burning retrograde, removing energy, soe gets smaller, sma and apoapsis greater.

apoapsis: -4018355

apoapsis: -5677602

apoapsis: -79147548

until soe crosses 0 and becomes negative, apoapsis starts to come down from infinity.

apoapsis: +3312767, soe < 0 again

apoapsis: +2342288

Once your apoapsis becomes smaller than soi KSP will show you a closed orbit.

Geometrically apoapsis flip to the opposite side of the opening of the hyperbola. That and due to the maths it becomes negative.

The vertex at the end of the blue line is the soi. It is due to KSP's approach on how to deal with gravity that the soi differs from the physics of an escape orbit. periapsis, apoapsis, velocity:orbit:mag, altitude are all about the potential and kinetic energy in the system.

So why is soi so different from the energy escape orbit?

The soi radius is used in KSP to simplify calculating gravitation. Within the soi only the body inside pulls at your ship (simple to calculate two body problem). All others planets, moon like Kerbin or the Sun are ignored. This is grossly wrong but good enough for the game and good enough for estimating transfers in reality. The soi is the boundary where Mun and Kerbin's gravitational force are equal. At the soi - in reality - your vessel will not move, in the game it falls to one of the bodies. That is why the game does not have Lagrange points.

Essentially that is why physics and the soi vertex on the blue trajectory line do not match.

Actually the guys who coded KSP obviously used the physical properties to determine status and not the soi.

For getting the soi (or the radius) of a body you need to build a database - or better: we make those constants available in kOS.

Btw: I agree with Camacha on: as a rule in a software system you should not change existing variables because it will break existing code. Instead add a new one. (Unless there is a very good reason to change it...)

I'm aware of everything you said here. It does not cause the problem to go away, nor does it make it magically stop being a problem no matter how much you keep repeating the mantra that it "works as designed". You just accurately described what's wrong, which is, in a nutshell, that what the laws of physics claims your apoapsis is, is not in agreement with what it actually is in the simulation, and for the sake of an autopilot, what we need to know is what the simulation thinks it is, not what the laws of physics claims it is. If I want to burn retrograde until captured, I have no choice but to use what the KSP simulation thinks of as escaping, which is not what physics claims is escaping, nor is it what status="ESCAPING' claims is escaping.

And there is a difference between a number that happens to work in a degenerate case and a number that means what it's defined as. A negative apoapsis violates the definition of what an apoapsis IS.

A far better solution is to get the eccentricity as a direct query, rather than to falsify the apoapsis to let you calculate eccentricity from it and in so doing to break the ability to detect whether or not you're going to exit the SOI.

Edited November 28, 2013 by Steven Mading

[Dunbaratu]

The script seems to deliver results which are not completely wrong but I can't verify that the calculated true anomaly is correct. Further to this, the calculated altitude and speed always seem to be corresponding to the periapsis even when I enter different mean anomalies.

I frequently find that I get numbers that are close to correct but not exactly correct when trying to use inverse trig functions like arctan.

Trying to calculate where the ascending and descending nodes were between me and a target for the sake of doing an inclination correction had the same problem, where it was always off by just a degree or so, untill I used larger vectors for it. (i.e. finding the dot product of two unit vectors and then getting the cosine from that dot product seems to be rather error prone, whereas doing it with the full length vectors instead of with unit vectors, gets a far more accurate answer.)

[Camacha]

And there is a difference between a number that happens to work in a degenerate case and a number that means what it's defined as. A negative apoapsis violates the definition of what an apoapsis IS.

I get the feeling this naming thing is important to you, possibly too important. In itself it is no reason to remove the variable from the system. It could be called Fluxorp517394negative, if it is useful, it should be retained. If there is no pull request to implement a better variable, is should be left alone.

Breaking something that is possibly broken - but useful - is not the right way to go without providing a viable alternative.

[Sacred Aardvark]

Breaking something that is possibly broken - but useful - is not the right way to go without providing a viable alternative.

I can't understand half the things you guys are talking about most of the time, so I'll just settle for QFT

Lot of the stuff I do in kOS probably doesn't work like its supposed to, and I've done stuff that definitely doesn't work like it's supposed to, but it does work for what I use it for which is all that matters in the end, to me anyway.

edit: Just to clarify a bit, I'm all for fixing broken stuff if there's a viable alternative to whatever can be done with the broken thing.

Edited November 29, 2013 by Sacred Aardvark

[baloan]

I'm aware of everything you said here. It does not cause the problem to go away, nor does it make it magically stop being a problem no matter how much you keep repeating the mantra that it "works as designed". You just accurately described what's wrong, which is, in a nutshell, that what the laws of physics claims your apoapsis is, is not in agreement with what it actually is in the simulation, and for the sake of an autopilot, what we need to know is what the simulation thinks it is, not what the laws of physics claims it is. If I want to burn retrograde until captured, I have no choice but to use what the KSP simulation thinks of as escaping, which is not what physics claims is escaping, nor is it what status="ESCAPING' claims is escaping.

Yes, right. I don't see the discrepancy between two models in KSP (patched conics, Kepler orbits) as a problem but as a feature. That's why it is really hard for me to follow your reasoning. The problem does not go away as long as KSP is based on those models to build its universe. And while you are within the SOI everything matches.

And there is a difference between a number that happens to work in a degenerate case and a number that means what it's defined as. A negative apoapsis violates the definition of what an apoapsis IS.

I agree that apoapsis does not make sense as "highest point of orbit" in all cases. But I care a lot about mathematical consistency. A negative apoapsis goes nicely with conservation of energy and the mathematical construct around it. And here apoapsis, periapsis, semi-major axis, eccentricity, specific orbital energy are all well defined.

Instead of touching any of those variables apoapsis, periapsis, altitude, velocity:orbit I'd rather see new ones added, for example with a prefix. Gets the best of both views.

[Kass]

Sorry if this has already been asked but what does the "^" symbol mean? I've seen it in a few example scripts and have no idea.

Please be gentle in your explanations, I've never coded anything before, although I'm currently trying to write a PID script for my skycrane (and failing).

Thanks in advance

I totally love this mod. My install with KOS, RT, RSS, FAR, ScanSat and a few other mods takes everything to a whole new level.