kOS Autopilot

[Camacha]

I just remembered there was some discussion on having kOS run a standard script upon boot, enabling recovery of units that lose contact or vehicles automatically resuming when reloaded. Do you think something like that can be implemented?

Edited February 16, 2014 by Camacha

[Buttons840]

I saw on the kOS wiki (http://kos.wikia.com/wiki/List_of_all_Commands) that an up coming feature is "T() Value = new TimeSpan(parameters[0]);" Please, please, please don't take inspiration from Java and add stuff like the new keyword.

[Dunbaratu]

I saw on the kOS wiki (http://kos.wikia.com/wiki/List_of_all_Commands) that an up coming feature is "T() Value = new TimeSpan(parameters[0]);" Please, please, please don't take inspiration from Java and add stuff like the new keyword.

1. There is nothing bad about the 'new' keyword.

2. That syntax is so unlike kOS that it would really require quite a change to the parser in ways a lot more drastic than just adding the 'new' keyword. I doubt it will look anything like that shorthand statement.

[Dunbaratu]

I just remembered there was some discussion on having kOS run a standard script upon boot, enabling recovery of units that lose contact or vehicles automatically resuming when reloaded. Do you think something like that can be implemented?

Boot is slightly different from reloading. A SCS unit that loses power and then regains power (i.e. solar panels go into shadow a long time and then come back into the sun later) does actually reboot, but an SCS unit was "on rails" and then becomes loaded into the physics engine again does not go through the "boot". Instead the mod attempts to put the unit right back where it was, in the same state - a bit like a computer going into sleep mode and then being re-awakened and it continues running programs where it left off. Back in version 0.9x that feature was still rather broken and untested (partly because the variable save/load bug made it moot anyway) but I saw that the attempt to do that was in the code. I don't know if 0.10 and up have messed with it much or not. I haven't tested it yet.

But the point I wanted to bring up is that if a 'run on bootup' feature was implemented it would probably not quite cover both those two cases you mention, for that reason.

[erendrake]

I just remembered there was some discussion on having kOS run a standard script upon boot, enabling recovery of units that lose contact or vehicles automatically resuming when reloaded. Do you think something like that can be implemented?

It can surely be implemented, Right now im working on Direct flight, rcs control so we can accomplish docking missions more easily. Having some kind of bootstrapper should be doable

Actually what i have been working on most lately has been the documentation site http://erendrake.github.io/KOS/, I think im ready for the community to review and tell me where i messed up.

[erendrake]

I saw on the kOS wiki (http://kos.wikia.com/wiki/List_of_all_Commands) that an up coming feature is "T() Value = new TimeSpan(parameters[0]);" Please, please, please don't take inspiration from Java and add stuff like the new keyword.

1. There is nothing bad about the 'new' keyword.

2. That syntax is so unlike kOS that it would really require quite a change to the parser in ways a lot more drastic than just adding the 'new' keyword. I doubt it will look anything like that shorthand statement.

I agree with Steven. What has the new keyword ever done to you? I think it makes for clearer code when you are explicitly creating new structures.

However, I have no plans for adding that keyword to KOS. the example in the wiki is pseudocode. Do we think that a timespan structure would be useful for scripters?

[erendrake]

Boot is slightly different from reloading. A SCS unit that loses power and then regains power (i.e. solar panels go into shadow a long time and then come back into the sun later) does actually reboot, but an SCS unit was "on rails" and then becomes loaded into the physics engine again does not go through the "boot". Instead the mod attempts to put the unit right back where it was, in the same state - a bit like a computer going into sleep mode and then being re-awakened and it continues running programs where it left off. Back in version 0.9x that feature was still rather broken and untested (partly because the variable save/load bug made it moot anyway) but I saw that the attempt to do that was in the code. I don't know if 0.10 and up have messed with it much or not. I haven't tested it yet.

But the point I wanted to bring up is that if a 'run on bootup' feature was implemented it would probably not quite cover both those two cases you mention, for that reason.

I think that my preference with something like this would be to let each of you register an external to run on boot, something like

REGISTER BOOTSTRAPPER TO <FILENAME>

And maybe even one for when you are losing power like:

REGISTER POWERLOSS TO <FILENAME>

And so on. I can think of a bunch of events that we might want to listen for. I also like giving control to you rather than just saving all state and magically restore it back to you.

Edited February 17, 2014 by erendrake

[Camacha]

But the point I wanted to bring up is that if a 'run on bootup' feature was implemented it would probably not quite cover both those two cases you mention, for that reason.

You are right, the way I put it made it sound like the same feature. The way you describe it is accurate.

It can surely be implemented, Right now im working on Direct flight, rcs control so we can accomplish docking missions more easily. Having some kind of bootstrapper should be doable

Direct flight for normal and RCS controls is a very nice feature to have. It will make life even harder (no more lock steering abuse for me), but a lot more interesting.

I think the idea was to make a bootstrapper that could be primed through the VAB description, enabling the user to 'bake' some basic commands and a script to copy from archive upon launch into each craft. Maybe that is a bit too complicated for now, but that would be a pretty neat feature for putting craft as finished products on the launchpad.

[erendrake]

putting craft as finished products on the launchpad.

This is a pretty compelling idea. I was very interested in using the description until i could not find a way to actually get at it through the API

Faced with the idea of having to persist that data in the craft file, I decided to work on some lower hanging fruit first.

[Dunbaratu]

I think that my preference with something like this would be to let each of you register an external to run on boot, something like

REGISTER BOOTSTRAPPER TO <FILENAME>

And maybe even one for when you are losing power like:

REGISTER POWERLOSS TO <FILENAME>

And so on. I can think of a bunch of events that we might want to listen for. I also like giving control to you rather than just saving all state and magically restore it back to you.

I'd like to register my approval of this idea for power off. (But not for going on/off rails, as I think that restoring code state for that makes more sense as on/off rails is a sort of breaking 4th-wall simulation artifact.)

Shouldn't the hook be called POWERRESUME rather than POWERLOSS? Presumably it would run the code when the power comes back on again, not when it gets lost.

I assume the <FILENAME> has to be local to the SCS unit for powering up, as I assume the SCS unit would forget the state of "switch to ...." when powered off. But would that be true of all hooks?

Edited February 17, 2014 by Steven Mading

[Dunbaratu]

#4 I think kOS definitely should have more flow control. Something akin to sys.exit(); to terminate a program at that point. As well as continue; and break; equivalent statements.

There really should be two different types of 'early quit', analogous to "exit" and "return" in most languages.

"exit" = end the whole process.

"return" = just quit the current routine. (which in the case of kOS means the current script file program).

They'd behave identically when just running one program, but differ when program calls are nested in other program calls.

[erendrake]

I think the idea was to make a bootstrapper that could be primed through the VAB description

I now realize that the ALCOR project found a way to get this data, its pretty crazy to get it but im going to give it a shot

[Camacha]

I understand the current work is on direct inputs (QEWASD and translations), right? I was wondering how accurately this can be controlled. Is it a matter of on/off or is there more in between, like what possible with analog sticks?

I now realize that the ALCOR project found a way to get this data, its pretty crazy to get it but im going to give it a shot

I love your fire, man. Make sure you do not burn yourself up!

They'd behave identically when just running one program, but differ when program calls are nested in other program calls.

I would like some more clarity when it comes to nested behaviour too. I found that previously nesting would work one way, but not the other. Running a script that started another version of itself each time it ran and then issuing a break command it exited all instances of it. I guess you would call it flow control when asking for some insight in the process and means to direct it.

Edited February 18, 2014 by Camacha

[erendrake]

I understand the current work is on direct inputs (QEWASD and translations), right? I was wondering how accurately this can be controlled. Is it a matter of on/off or is there more in between, like what possible with analog sticks?

it looks like it will work like this, there are 6 controls:

pitch,

roll,

yaw,

xTranslate, (anyone have a better name for these?)

yTranslate,

zTranslate

they are all floats and should accept any value between 1 and -1 i think? im not 100% on the domain.

there will also be two flags you can toggle:

Neutral,

Kill

neutral just resets everything to 0,

kill takes over and tries to steady your ship.

there are a few other properties in the bag like trim that i havent hooked up yet and might not, not sure.

I love your fire, man. Make sure you do not burn yourself up!

Ill try

[Camacha]

it looks like it will work like this, there are 6 controls:

they are all floats and should accept any value between 1 and -1 i think? im not 100% on the domain.

Funny, I thought to myself that might be useful to set it up like the throttle control. Apparently you came to the same conclusion If you are going to arbitrarily pick a domain, I feel that picking one akin to the throttle control is a fair way to go.

[Camacha]

it looks like it will work like this, there are 6 controls:

xTranslate, (anyone have a better name for these?)

yTranslate,

zTranslate

Maybe xaxis, yaxis and zaxis? Or axisx, axisy and axisz, for that matter. I am not too fond of fumbling around with capitals, as those were not required in kOS. The x, y and z terms should definitly be in the names though, as that makes it very clear what is going on and if not, Wikipedia and the internet are full of explanations what that means.

there will also be two flags you can toggle:

[...]

Kill

How should I view this? As something like ASAS?

Edited February 18, 2014 by Camacha

[erendrake]

Maybe xaxis, yaxis and zaxis? Or axisx, axisy and axisz, for that matter. I am not too fond of fumbling around with capitals, as those were not required in kOS. The x, y and z terms should definitly be in the names though, as that makes it very clear what is going on and if not, Wikipedia and the internet is full of explanations what that means.

sorry about the caps, they are not required, we are still case insensitive for things like this

How should I view this? As something like ASAS?

Sure, I am not sure if it is actually is the same as SAS but its in the API and i think its useful.

[Dunbaratu]

I'm against the idea of using the nomenclature "x,y,z" for direct RCS translation control (i.e. the HNIJKL keys).

This is because there's already a frame of reference in the game using x,y,z axes that are oriented with the orbital body not the vessel. (where Y is north, and the XZ plane is the equator), and axes in this direction are what is used every time you get a vector's XYZ parts in kOS.

Calling the vessel's orientation by the same naming convention would really be confusing because the X,y,z you're talking about when steering the vessel would be different from when doing everything else in kOS.

How about making it clear that it's relative to the vessel by calling the 6 directions something like Fore, Aft, Port, Starboard, Top, and Bottom? (or left and right if you prefer that to port and starboard). You could have the 3 axes being called Fore, Starboard, Top. (That's a left-handed system akin to the rest of Unity. If you want a right-handed system then change Starbaord to Port.)

(I sugested "top" rather than "up" because there's already an "up" direction that means something else in kOS).

[Camacha]

This is because there's already a frame of reference in the game using x,y,z axes that are oriented with the orbital body not the vessel. (where Y is north, and the XZ plane is the equator), and axes in this direction are what is used every time you get a vector's XYZ parts in kOS.

Is this integral to kOS and available and out in the open for the user? Because if it is something under the hood - or something that should be under the hood - I think it does not really matter that it is already in use. However, if there is a legitimate concern that confusion may arise, nomenclature should be appropiately adjusted - but I would strongly suggest to keep it in line with x, y and z conventions. Those are so well known that I would loathe to change it unless it is absolutely necessary.

To be honest, I think some stuff currently in kOS should not be there to see for the user. It is fine that KSP uses strange internal trickery to get the numbers to work on a solar system scale, but KSP and kOS users should not be confronted with Euler rotations that are relative to different objects at different times and that change seemingly arbitrarily. If at all possible, values should be translated into the real world numbers that engineers also have to deal with when solving the problems that users are trying to solve with kOS. Not only does that make things easier to understand, you will also learn more actually useful stuff (rather than learning a lot about the obscure inner workings of KSP).

[erendrake]

Is this integral to kOS and available and out in the open for the user? Because if it is something under the hood - or something that should be under the hood - I think it does not really matter that it is already in use. However, if there is a legitimate concern that confusion may arise, nomenclature should be appropiately adjusted - but I would strongly suggest to keep it in line with x, y and z conventions. Those are so well known that I would loathe to change it unless it is absolutely necessary.

To be honest, I think some stuff currently in kOS should not be there to see for the user. It is fine that KSP uses strange internal trickery to get the numbers to work on a solar system scale, but KSP and kOS users should not be confronted with Euler rotations that are relative to different objects at different times and that change seemingly arbitrarily. If at all possible, values should be translated into the real world numbers that engineers also have to deal with when solving the problems that users are trying to solve with kOS. Not only does that make things easier to understand, you will also learn more actually useful stuff (rather than learning a lot about the obscure inner workings of KSP).

I agree that there should be consistency and ease of use for KOS users. I am willing to add as much complexity to KOS itself as needed to abstract API weirdness. I have a stranger idea for how to deal with both the rotational and translational setting. How would you feel with something like this?

 
LOCK TRANSLATION TO V(1,-0.25,0). 
LOCK ROTATION TO V(0,0,-1).

This would only work for the active vessel and I'm not 100% on this being a schematically correct use of vector

For all vessels We could use

SET TARGET:CONTROL:TRANSLATE TO V(1,-0.25,0). 
LOCK TARGET:CONTROL:ROTATE TO V(0,0,-1).

[erendrake]

I'm against the idea of using the nomenclature "x,y,z" for direct RCS translation control (i.e. the HNIJKL keys).

This is because there's already a frame of reference in the game using x,y,z axes that are oriented with the orbital body not the vessel. (where Y is north, and the XZ plane is the equator), and axes in this direction are what is used every time you get a vector's XYZ parts in kOS.

Calling the vessel's orientation by the same naming convention would really be confusing because the X,y,z you're talking about when steering the vessel would be different from when doing everything else in kOS.

How about making it clear that it's relative to the vessel by calling the 6 directions something like Fore, Aft, Port, Starboard, Top, and Bottom? (or left and right if you prefer that to port and starboard). You could have the 3 axes being called Fore, Starboard, Top. (That's a left-handed system akin to the rest of Unity. If you want a right-handed system then change Starbaord to Port.)

(I sugested "top" rather than "up" because there's already an "up" direction that means something else in kOS).

I agree with you that XYZ are overloaded, this is why i asked for suggestions for names. I think that if we explicitly call out the XYZ axis in the documentation calling it STARBOARD/TOP/FORE makes sense. I do like the nautical wording as they are very explicit.

[Camacha]

How would you feel with something like this?

 
LOCK TRANSLATION TO V(1,-0.25,0). 
LOCK ROTATION TO V(0,0,-1).

This would only work for the active vessel and I'm not 100% on this being a schematically correct use of vector

I am not sure you would need to (or should) call it a vector. Just the three terms would work for me. But doing it that way is not a bad idea. You can independently control each axis within the earlier discussed -1 to 1 domain and pretty much everything in between. I think I like it

Two things come to mind:

- I would personally like the ability to set something to a value instead of just locking it. Now, it is impossible to set the throttle to 50% without also denying the user any input.

By the same token, reading current throttle and probably rotation and translation values would be desirable. I would love to be able to readout what throttle setting the user set. Something like print throttle or set throtval to throttle would be sufficient I think. It would conveniently also be most of what is needed for indirect user control (fly-by-wire) capabilities, although some thought needs to be put into how to seperate user input from kOS output.

- For maximum flexibility it would be nice to be able to set one value without having to touch the others. That way I could write a script that would just prevent craft rotation, but leaves the user free to pitch and yaw as desired.

For all vessels We could use

SET TARGET:CONTROL:TRANSLATE TO V(1,-0.25,0). 
LOCK TARGET:CONTROL:ROTATE TO V(0,0,-1).

As long as we are careful not to string these things together too much (lock orbit:mun:target:control:rotate:periapsis:time to 2 ), that should work.

I guess it is a matter of finding a balance between hierarchy - and thus predictability - and keeping things legible and easy to use.

Please excuse any wonky language, very little sleep and lots of coffee.

Edited February 18, 2014 by Camacha

[Dunbaratu]

I agree with you that XYZ are overloaded, this is why i asked for suggestions for names. I think that if we explicitly call out the XYZ axis in the documentation calling it STARBOARD/TOP/FORE makes sense. I do like the nautical wording as they are very explicit.

I like the terms because they make it 100% crystal clear that what you are dealing with is a frame of reference that rotates with the ship. It's clear that "fore" can't be anything other than the direction the nose is pointed.

As for the other confusion over xyz changing its frame of reference willy-nilly because of how KSP solved the space kraken problem, I agree that that could be cleared up (although it *definately* would introduce backward compatibility problems, it's better to do that earlier rather than later). It would be useful if kOS always returned values in the fixed-planet reference system instead of sometimes using the rotating-planet reference system. (That would mean normalizing the X and Z axes to always be the same longitude lines.) But that would require quite an overhaul in the code, as you'd have to remember to always run all user-supplied coordinates through the transformation before sending them to the KSP API functions.) And on that subject, another point of real confusion is how the *ORIGIN* of the XYZ system keeps changing depending on what value you're retrieving, not just on where you are. For example, the POSITION of a body is its position relative to your ship, while the VELOCITY of it is its velocity relative to your current SOI body. The fact that position and velocity are measured in frames of reference that don't have the same origin point is really messy and utterly non-intuitive. (thankfully they do have the same rotation other wise it would be even more messy).

[Camacha]

Yes, that is exactly the kind of stuff users should never deal with. I know the back end is probably going to be a pain, but fixing it suits the intention and purpose of kOS perfectly.

[Dunbaratu]

This would only work for the active vessel and I'm not 100% on this being a schematically correct use of vector

Despite what I said about avoiding the terms X,Y, and Z, if Vectors were used I'd prefer to keep the terms X Y and Z. The terms Fore/starboard/top would be used if we weren't using Vectors at all. I do sort of see a problem in that vectors are handy thing to have and yet the terminology could confuse people…. I'm now waffling on what's the better thing to do.

The thing I fear is someone combining operations between the games' other vectors and the 'docking vectors' and thinking they're the same X Y and Z axes. But the other thing is that being able to treat docking operations with vectors would open up a lot of useful things like using dot and cross products to help you calculate docking moves. These two goals are in direct contradiction…. Hmmm…

I'm sure you've seen the stuff I put on the wiki ages ago about rotating frames of reference between native XYZ and north/east/up coordinates. What I'm now wondering is whether or not what kOS needs is a few frame-of-reference translation functions that users can call, like so:

set vel to velocity:orbit.
set relVel to coordSpaceToShip( vel ).
print "I am drifting at " + relVel:y + " m/s toward my roof.".
print "I am drifting at " + relVel:x + " m/s toward my right.".
print "I am drifting at " + relVel:z + " m/s forward.".

i.e.

coordSpaceToShip() : input a vector in KSP's XYZ system. outputs a vector in ship-relative system.

coordShipToSpace() goes the other way.

coordSpaceToGeo() : inputs a vector in KSP's XYZ system. Outputs a vector in the current east/north/up.

coordGeoToSpace() goes the other way.

The thing is, by adding these functions to the language, you'd make it explicitly clear to users that the XYZ of vectors can be in different frames of reference, and get them used to the idea that the X of one vector might not be the same as the X of another vector. Maybe if these functions existed then having different meanings of X Y and Z wouldn't be as confusing as I had first thought.

There's a part of me that feels a bit prideful that I worked out how to deal with XYZ's in KOS and do stuff like those transformations on my own with just trial and error and investigation at the terminal to work out what the coordinate grid is actually like, but I also recognize that having to do that was just silly and shouldn't have been necessary. Maybe providing these as built-ins would be a good idea.

(On that subject, also the ability to convert between Direction and Vector, another thing I made a small program using transformation matrices for, would be nice. Obviously when going from Direction to Vector you have no magnitude for the vector, so you just make it a unit vector, and when going from vector to Direction you have no roll information so you have to just pick an arbitrary roll.)