kOS Scriptable Autopilot System 0.9

[Amloris]

Post #2047

One simple thing that it might be is just this: Where was the keyboard focus when you pressed ALT-1? The trick of using action groups as a roundabout way to get live key input requires that you are in the camera view (not map view) and that the terminal window NOT be focused. It has to be "greyed out" because unless your kepressess are passing through to the KSP game, hitting ALT-1 doesn't trigger action group 1.

Unfortunately, none of those suggestions manage to get the code to work. When the KOS window is unfocused and the game is in camera view the code will not recognize any actionkey input.

Even using the coding directly supplied by the KOS Space Computer yields similar results.

I suppose I can get my code to respond to external input by using the landing gear, brakes, rcs and sas keys to act as external input during the prelaunch sequence, but I would much rather get it to work by using the action keys.

Any suggestions?

[wingnut]

Maybe there are more, but I am sure they will be of the same type. kOS does not like unmatched quotation marks at all. Leaving any in your code is bound to result in a lock-up. Your code should be:

D'oh. Thanks. I already figured it had something to do with the print or log statements but I did not spot the incorrect strings.

[Camacha]

Unfortunately, none of those suggestions manage to get the code to work. When the KOS window is unfocused and the game is in camera view the code will not recognize any actionkey input.

That is weird. In a very broken bit of test code I wrote earlier this week, kOS will only respond to unfocussed commands. I have not gone any further with it and is not how you should write something like this, but maybe it is of some help. This is tested with the most recent official version of kOS.

until ship:liquidfuel < 20 {
  if altitude < altset {run ascscript.}.
  if altitude > altset {run descscript.}.
  if ag2 = "True" {set altset to altset - 10. ag2 off.}.
  if ag3 = "True" {set altset to altset + 10. ag3 off.}.
}.

D'oh. Thanks. I already figured it had something to do with the print or log statements but I did not spot the incorrect strings.

They can be pretty hard to spot

[Dunbaratu]

I did read that but there are a couple of missing pieces that are still throwing me off:

1) As you said when I query Duna:position the vector's origin is my craft and not the Kerbin centered XYZ described in the Wiki. The wiki page explain the XYZ system when Kerbin is the origin but not when the the craft is the origin. I would need to transform Duna:position into a common coordinate system before doing any vector math. I am not sure how to do this since I don't know their systems orientation wrt each other.

It appears to be in the same orientation. A different origin point, but the same orientation. So the only operation needed is a translation, not a rotation. I've had success getting the Mun's position relative to Kerbin by just doing simple vector tip to tail addition - adding (my position from Kerbin) to (Mun's position from me) to get (Mun's position from Kerbin).

2) Kerbin:BODY:position seems to give me my position with respect to a Sun centered origin. However, again this seems to have a different origin I would need some information to transform the coordinates.

Kerbin:BODY:position does not give you YOUR position at all, in ANY frame of reference. Period. It gives you The Sun's position. Because Kerbin:BODY means "The body that Kerbin orbits", i.e. "the sun".

However, I can't add the vectors until they are all in the same coordinate system with the same origin.

That's not true. They have to be in coordinate systems that have the same orientation, but don't need the same origin to add them together. In fact that's pretty much the definition of vector addition of vector A to vector B. You're making vector B be "origined" at the tip of vector A.

[AeroEngy]

It appears to be in the same orientation. A different origin point, but the same orientation. So the only operation needed is a translation, not a rotation. I've had success getting the Mun's position relative to Kerbin by just doing simple vector tip to tail addition - adding (my position from Kerbin) to (Mun's position from me) to get (Mun's position from Kerbin).

Kerbin:BODY:position does not give you YOUR position at all, in ANY frame of reference. Period. It gives you The Sun's position. Because Kerbin:BODY means "The body that Kerbin orbits", i.e. "the sun".

Perhaps, but it is just semantics whether it points from craft > sun or sun < craft as that is just the difference in A vs -A in my crappy drawing. I originally thought it would points from sun>kerbin or vise versa. But since it has a oscillating non-zero value for the y-component that corresponded to me cross the equator this is certainly not the case. If this XYZ system is in the same orientation as the craft and Kerbin then it because trivial to calculate phase angle.

That's not true. They have to be in coordinate systems that have the same orientation, but don't need the same origin to add them together. In fact that's pretty much the definition of vector addition of vector A to vector B. You're making vector B be "origined" at the tip of vector A.

You are correct and that is what I meant. It seemed from the vector components coming back from Duna:position that the orientation was not the same between Kerbin center and craft centered coordinates. Maybe I am making this more complicated than it needs to be. In my real job I am used to having to transform from ECEF, ECI, NED, and other vehicle centric systems.

Edited November 26, 2013 by AeroEngy

[Bizz Keryear]

I did read that but there are a couple of missing pieces that are still throwing me off:

1) As you said when I query Duna:position the vector's origin is my craft and not the Kerbin centered XYZ described in the Wiki. The wiki page explain the XYZ system when Kerbin is the origin but not when the the craft is the origin. I would need to transform Duna:position into a common coordinate system before doing any vector math. I am not sure how to do this since I don't know their systems orientation wrt each other.

2) Kerbin:BODY:position seems to give me my position with respect to a Sun centered origin. However, again this seems to have a different origin I would need some information to transform the coordinates.

Here is a crappy sketch of my thought process, what I believe each position vector represents and my issues,

A = Kerbin:BODY:position (origin at sun ?, xyz system unknown)

B = Kerbin:position (origin at craft, xyz system unknown)

C = Duna:position (origin at craft, xyz system unknown)

Goal determine vectors A+C and A+B (dashed lines) via simple vector addition. Calculate angle between using dot products.

However, I can't add the vectors until they are all in the same coordinate system with the same origin.

This might be of how KSP functions internally. Because Unity does not deal well with the vast scale of the Kerbin system, some trickery is involved where you do not move as much as you would think and the universe actually scales and moves around you. There are some interesting video's Squad made on this subject.

See here:

and

... I know nobody really wants to watch it, cause its freaking long and takes some time to get to the (floating) point (pun intended). I have set up the starting points... there might be more but I am also too lazy to watch it again (also on http://kos.wikia.com/wiki/XYZ_system_of_KSP [at the very bottom])

Unfortunately, none of those suggestions manage to get the code to work. When the KOS window is unfocused and the game is in camera view the code will not recognize any actionkey input.

Even using the coding directly supplied by the KOS Space Computer yields similar results.

I suppose I can get my code to respond to external input by using the landing gear, brakes, rcs and sas keys to act as external input during the prelaunch sequence, but I would much rather get it to work by using the action keys.

Any suggestions?

That is weird. In a very broken bit of test code I wrote earlier this week, kOS will only respond to unfocussed commands. I have not gone any further with it and is

not

how you should write something like this, but maybe it is of some help. This is tested with the most recent official version of kOS.

As Camcha said: No one before ever reported this. I myself hadn't this problem in any version I ever used.

One wild guess: Did you have installed any other mod?

If not try to post the code and a HD! video (Its important that it is HD or else we can't see what is going on, do not use a low bit rate either.)

Also important set a trigger indicator to the action groups you want to use ... I suggest lamps ... (since we can't see your fingers/ keyboard and the game screen at same time ... while writing this, this popped also in mind: Do not use a cell phone but a screen capture software to record. Even in HD the quality might be to low to see whats going on)

1. Attach lamps on the vessel (do not use symmetry mode!) in front so they can all be seen at the same time.
   
2. Now assign one lamp to each action group you want to use (use toggle).
   
3. start at least recording now.
   
4. While on the launch pad each action group (up to all 9 but you do really only need as much as you use in the demonstration ... while thinking about two or three should be enough in your case) should turn on one lamp. (and off if they are on already)
   
5. After checking this:
   
   1. 
      
   2. Open the kOS window
      
   3. Start the program in question
      
   4. Unfocus the kOS window through clicking somewhere (except kOS window)
      
   5. Hit any action group.
      
   6. ?????
   7. Profit!
      

Edited November 26, 2013 by Bizz Keryear

[Dunbaratu]

Perhaps, but it is just semantics whether it points from craft > sun or sun < craft as that is just the difference in A vs -A in my crappy drawing.

It is not trivial that you had the meaning of adding the suffix ":BODY" misunderstood. That will mess up everything else you try to do. In this *one* example case, all it does is change the sign, but in the general case, believing that Kerbin:BODY is Kerbin, when it's in fact the sun, will mess up lots of math you try to do.

[AeroEngy]

It is not trivial that you had the meaning of adding the suffix ":BODY" misunderstood. That will mess up everything else you try to do. In this *one* example case, all it does is change the sign, but in the general case, believing that Kerbin:BODY is Kerbin, when it's in fact the sun, will mess up lots of math you try to do.

Note sure where you got that I thought Kerbin:BODY was Kerbin. By my second post I had figured that out although the direction was backwards.

I got the magnitude of both Kerbin:BODY:pOSITION and DUNA:BODY:pOSITION. Both vectors looked almost the same with magnitudes of 1.36x10^10 [V(-7.4x10^9, -1.0x10^3, 1.1x10^10)] ... which made me guess this is my craft's position with respect to Kerbol.

Anyway, crappy sketch 2.0 below. If what you are saying is correct and X || X' || X'' & Y || Y' || Y'' & Z || Z' || Z'' Then the following should be true.

• 
  
• Vector K to from Kerbol to Kerbin is : kerbin:position - kerbin:body:position
  
• Vector D from Kerbol to Duna is: Duna:position - kerbin:body:position
  
• Phase angle between them is acos( K*D / ( ||D|| ||K|| ) {where * is the dot product.}
  

The main reason I originally doubted that Duna:position was in the same orientation was when I queried Duna:position I got V(3.5*10^9, -1.2x10^7,-5.1x10^9) That seemed high given the low inclination of Duna's orbit. (0.06 degrees) but doing some back of the napkin math that is in the range of possibility. I will do some more testing tonight and build a phase angle calculator assuming all of this and see what it spits out.

[Amloris]

That is weird. In a very broken bit of test code I wrote earlier this week, kOS will only respond to unfocussed commands. I have not gone any further with it and is not how you should write something like this, but maybe it is of some help. This is tested with the most recent official version of kOS.

snip

I tried your code that you provided and I still can't get it to recognize key input. I feel like I'm running into a brick wall here.

As Camcha said: No one before ever reported this. I myself hadn't this problem in any version I ever used.

One wild guess: Did you have installed any other mod?

If not try to post the code and a HD! video (Its important that it is HD or else we can't see what is going on, do not use a low bit rate either.)

Also important set a trigger indicator to the action groups you want to use ... I suggest lamps ... (since we can't see your fingers/ keyboard and the game screen at same time ... while writing this, this popped also in mind: Do not use a cell phone but a screen capture software to record. Even in HD the quality might be to low to see whats going on)

1. Attach lamps on the vessel (do not use symmetry mode!) in front so they can all be seen at the same time.
   
2. Now assign one lamp to each action group you want to use (use toggle).
   
3. start at least recording now.
   
4. While on the launch pad each action group (up to all 9 but you do really only need as much as you use in the demonstration ... while thinking about two or three should be enough in your case) should turn on one lamp. (and off if they are on already)
   
5. After checking this:
   
   1. 
      
   2. Open the kOS window
      
   3. Start the program in question
      
   4. Unfocus the kOS window through clicking somewhere (except kOS window)
      
   5. Hit any action group.
      
   6. ?????
   7. Profit!
      
      I currently have no mods besides KOS installed on this version of KSP. The KOS version I am using is v0.9.1, but I suspect it is the v0.9.2 version.
      When it gets a little more quiet around here I'll record a video of my dilemma; I have recording software and video editing software (I just need a brief refresher on how to use them!). I followed your suggestions with the lights as well as your testing suggestions, but sadly returned no positive results. I'll see if I can record that video later tonight.
      In the meantime, I have another problem that I have noticed in how KOS deals with trigonometric values that returns mathematically erroneous results that will be addressed in my next post.

[Camacha]

I tried your code that you provided and I still can't get it to recognize key input. I feel like I'm running into a brick wall here.

Since you are the only user reporting fundamentally different behaviour, it is starting to look like it has something to do with your setup. I would suggest trying a fresh copy of KSP and/or kOS.

[AeroEngy]

In case anyone was interested I made the following to calculate the phase angles between any 2 planets orbiting the Sun/Kerbol

You just pass it the name of the current body and target body as a string run phaseAngle("Kerbin","Duna") for example. currentBodyStr doesn't actually have to be your "current" body but I didn't feel like renaming the parameters. Currently this just spams the angle to the terminal forever (ctrl+C to stop) but it could be modified to return the angle or setup to wait for an optimal angle for transfer.

Notes:

I also switched form using the BODY:BODY:POSITION vectors to SUN:POSITION. I didn't know that actually existed as I was trying Kerbol before ... oh well live and learn. This is a 2-D approach using arctan with quadrant based corrections instead of dot products. I thought it would be easier but after applying all the fixes ... it probably wasn't. Also there is probably a better way to assign bodies besides my big block of repetitive IF statements ... but I got lazy with the copy and paste.

//Calculate how many degrees ahead target is from current body
// pass in current and target bodies as strings
declare parameter currentBodyStr. 
declare parameter targetBodyStr.

clearscreen.
if currentBodyStr = "Moho" {set Cbody to Moho.}.
if currentBodyStr = "Eve" {set Cbody to Eve.}.
if currentBodyStr = "Kerbin" {set Cbody to Kerbin.}.
if currentBodyStr = "Duna" {set Cbody to Duna.}.
if currentBodyStr = "Dres" {set Cbody to Dres.}.
if currentBodyStr = "Jool" {set Cbody to Jool.}.
if currentBodyStr = "Eeloo" {set Cbody to Eeloo.}.
Print "Current Body Set to: " + cbody:name.

if targetBodyStr = "Moho" {set Tbody to Moho.}.
if targetBodyStr = "Eve" {set Tbody to Eve.}.
if targetBodyStr = "Kerbin" {set Tbody to Kerbin.}.
if targetBodyStr = "Duna" {set Tbody to Duna.}.
if targetBodyStr = "Dres" {set Tbody to Dres.}.
if targetBodyStr = "Jool" {set Tbody to Jool.}.
if targetBodyStr = "Eeloo" {set Tbody to Eeloo.}.
Print "target Body Set to: " + Tbody:name.

Until 0 {
SET C to cBody:POSITION - SUN:POSITION.
SET T to Tbody:POSITION - SUN:POSITION.

//Just use 2-D case and skip dot products
SET CAngle2d to arctan(C:x/C:z).
Set TAngle2d to arctan(T:x/T:z).

//Fix when z = 0 leading to undefined arctan
if C:z = 0 AND C:x > 0 {SET CAngle2d to 90.}.
if C:z = 0 AND C:x < 0 {SET CAngle2d to 270.}.
if T:z = 0 AND T:x > 0 {SET TAngle2d to 90.}.
if T:z = 0 AND T:x < 0 {SET TAngle2d to 270.}.

//fix quadrant 2 & 3 to get correct angle due to sign issues.
if C:z < 0 {SET CAngle2d to CAngle2d + 180.}.
if T:z < 0 {SET TAngle2d to TAngle2d + 180.}.
//fix quadrant 4
if C:x < 0 AND C:z > 0  {SET CAngle2d to CAngle2d + 360.}.
if T:x < 0 AND T:z > 0  {SET TAngle2d to TAngle2d + 360.}.

set phaseAngle to CAngle2d - TAngle2d.
if phaseAngle < 0 {SET phaseAngle to phaseAngle +360.}.  //I don't like negative angles
PRINT "Phase Angle: " + round(phaseAngle,1) at (0,2).
wait 1.
}.

[adammada]

@AeroEngy

Oh my, you complcated this SOOOO MUCH, when you could do it that way:

DECLARE PARAMETER body1.
DECLARE PARAMETER body2.


SET body1p TO body1:position - body1:body:position.
SET body2p TO body2:position - body1:body:position.	
SET phaseangle TO ARCTAN2(body1p:x,body1p:z) - ARCTAN2(body2p:x,body2p:z).
if phaseangle < -180 {
	SET phaseangle TO phaseangle + 360.
}.	
if phaseangle > 180 {
	SET phaseangle TO phaseangle - 360.
}.	

And if you want arguments to be body names not bodies istelf, just do:

declare parameter currentBodyStr. 
declare parameter targetBodyStr.

set Cbody to BODY(currentBodyStr).
set Tbody to BODY(targetBodyStr).

That way you can get phase angle between moons, not just planets (if for example you want to go from Mun to Minmus).

[AeroEngy]

@AeroEngy

Oh my, you complcated this SOOOO MUCH, when you could do it that way:

DECLARE PARAMETER body1.
DECLARE PARAMETER body2.


SET body1p TO body1:position - body1:body:position.
SET body2p TO body2:position - body1:body:position.	
SET phaseangle TO ARCTAN2(body1p:x,body1p:z) - ARCTAN2(body2p:x,body2p:z).
if phaseangle < -180 {
	SET phaseangle TO phaseangle + 360.
}.	
if phaseangle > 180 {
	SET phaseangle TO phaseangle - 360.
}.	

And if you want arguments to be body names not bodies istelf, just do:

declare parameter currentBodyStr. 
declare parameter targetBodyStr.

set Cbody to BODY(currentBodyStr).
set Tbody to BODY(targetBodyStr).

That way you can get phase angle between moons, not just planets (if for example you want to go from Mun to Minmus).

Thanks! I am quite good at making things complicated. I completely missed the existence of arctan2 when reviewing the available trig functions. I also didn't know you could call BODY("name") that way. Since the readme just said " BODY // The current celelestial body whose influence you are under".

Regarding moons I wanted to add something to prevent targeting bodies that had different parents. So I will probably use something like tbody:BODY:NAME to make sure it matches the same thing as the cBody's.

Which leads me to a question. Is there a way to list the elements of Structure. I feel like I am working in the dark not knowing all the elements of BODY or TARGET etc. The only reason I know of half of them is because I saw someone else use it somewhere.

[baloan]

We are looking into an issue using apoapsis in escape trajectories. Dunbaratu has found random apoapsis numbers while coasting in an escape trajectory. I cannot reproduce this behaviour. On the contrary I have found reproducably and mathmatically sound apoaspis figures (here). Anyone having the same problem with random apoapsis numbers? We are looking for a way to reproduce this issue. If you can, please let us know.

How to find out you are in a escape trajectory?

1. print status -> "ESCAPING", or check apoapsis > body's soi (soi numbers taken from the wiki)

2. Report orbital parameters

print body. // and

print periapsis. // for reference.

3. and then

print apoapsis

repeatedly. Please report if the numbers fluctuate between positive and negative numbers.

Apoapsis carries information about orbital energy both for elliptic orbits and hyperbolic (escape) trajectories. A pull request based on https://github.com/Nivekk/KOS/issues/248 removes apoapsis information for hyperbolic orbits for future kOS versions. It deprives kOS scripts of the ability to calculate deltav for injection burn maneuvers (for example, perinode(alt) will calculate injection burns out of the box with kOS 0.9.2)

Edited November 27, 2013 by baloan

[adammada]

We are looking into an issue using apoapsis in escape trajectories.

It pretty much depends on "apoapsis from where". For example, when i was going from Mun to Kerbin, (change SOI, but no encounter), ship:apoapsis was apoapsis from MUN which WOULD BE if not SOI change.

[mordieth]

Is there a way to keep a key pressed for a set amount of time? For instance the keys for action groups 1 and 2? Need to rotate parts for a certain time with infernal robotics

[Camacha]

Is there a way to keep a key pressed for a set amount of time? For instance the keys for action groups 1 and 2? Need to rotate parts for a certain time with infernal robotics

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.

[nothke]

A little countdown display and a better way to run through checklists =)

[Dunbaratu]

A pull request based on https://github.com/Nivekk/KOS/issues/248 removes apoapsis information for hyperbolic orbits for future kOS versions.

How can a pull request "remove" information that is already physically impossible? A hyperbolic orbit is one that by definition does not HAVE an apoapsis because it doesn't curve back and fall in again, and therefore there's no such thing as the "highest" altitude it will achieve. What I was asking for was a way to detect this scenario and stop returning bogus false numbers for apoapsis in this scenario like it does now.

Edited November 27, 2013 by Steven Mading

[Camacha]

What I was asking for was a way to detect this scenario and stop returning bogus false numbers for apoapsis in this scenario like it does now.

I think you would have to take advantage of the random nature of these bogus numbers. It might be possible to do this by monitoring the progression of the number for a while. When it varies too wildly within a certain period of time, it should be considered hyperbolic. Another method could be that the movement apoapsis should always have a certain direction .ie up or down. When it goes up and down a number of times you are on a hyperbolic trajectory.

[baloan]

How can a pull request "remove" information that is already physically impossible? A hyperbolic orbit is one that by definition does not HAVE an apoapsis because it doesn't curve back and fall in again, and therefore there's no such thing as the "highest" altitude it will achieve. What I was asking for was a way to detect this scenario and stop returning bogus false numbers for apoapsis in this scenario like it does now.

I agree, it does not make sense as "highest altitude of an orbit", BUT

the apoapsis variable carries information about orbital energy both for elliptic orbits and hyperbolic (escape) trajectories. Removing apoapsis information for hyperbolic trajectories removes information about the specific orbital energy which is required to calculate deltav for injection burn maneuvers (for example, perinode(alt) will calculate injection burns out of the box with kOS 0.9.2).

If you have fluctuating numbers in a hyperbolic orbit I'd like to reproduce those - it might be a bug. Please provide information on how to reproduce. I don't see random apoapsis numbers. If you provide apoapsis, periapsis, velocity:orbit:mag, body and altitude we can calculate the specific orbital energy to check those numbers make sense.

I'm referring to this change.

Edited November 27, 2013 by baloan

[Dunbaratu]

If you have fluctuating numbers in a hyperbolic orbit I'd like to reproduce those - it might be a bug. Please provide information on how to reproduce

Apparently providing that information once isn't enough. I already described it in the github issue.

[Dunbaratu]

the apoapsis variable carries information about orbital energy both for elliptic orbits and hyperbolic (escape) trajectories. Removing apoapsis information for hyperbolic trajectories removes information about the specific orbital energy which is required to calculate deltav for injection burn maneuvers (for example, perinode(alt) will calculate injection burns out of the box with kOS 0.9.2).

Even if it did consistently return a negative number that you can plug into the equation to get your eccentricity, it still wouldn't be correct to call that negative number an apoapsis.

Edited November 27, 2013 by Steven Mading

[Camacha]

Even if it did consistently return a negative number that you can plug into the equation to get your eccentricity, it still wouldn't be correct to call that negative number an apoapsis.

On the other hand, it is better to have an incorrectly named but useful number than no number at all.

[aNewHope]

On the other hand, it is better to have an incorrectly named but useful number than no number at all.

I can only agree with you, Camacha, only because the "apoapsis" is coded like this, my ∆V calculations work right out of the box.

Even on a hyperbolic trajectory I can e.g calculate the ∆V for a circularization burn.

Kevin (Laity), please don't remove this bug/feature/useful stuff.