[1.3] kOS Scriptable Autopilot System v1.1.3.0

[marianoapp]

there is a way to pass a variable between them?

Not yet...

[sirkut]

I was curious if the RegisterkOSExternalFunction would be implemented so I could see if I could resume work on getting Infernal Robotics working again with kOS. I did have success in using it except I didn't tackle specific groups or call individual robotic parts yet.

[baloan]

@baloan: Anyway it could be possible to integrate kOS and kRPC so our virtual machine sends instructions to it instead of interfacing with KSP itself' date=' but it would be necessary to [b']evaluate the pros and cons of doing that.

Using kRPC/Python puts whatever language and development environment you use right into the spacecraft (without time delay). This is very comfortable and productive for development though defeats the idea of an "Apollo"-like restricted environment. For me as an avid user of "switch to 0." when running kOS it does not make much of a difference - but for others who play with remote tech or similar it will be a con that the restriction features are not readily available (and maybe difficult to implement).

I like the idea of using readily available packages with Python like vector math packages, Lambert solvers which allow for more consistent treatment of vector arithmetic and easier handling of a 3D approach to orbital mechanics. I am still fighting with the concept of pitch, yaw and roll and the continuously changing frames of reference in KSP/kOS.

[Dunbaratu]

and the continuously changing frames of reference in KSP/kOS.

I am forever annoyed that KSP keeps altering the XYZ frame of reference during play. I've added a change (that I hope will make it into kOS soon) that lets you view the actual vectors drawn on the screen in 3D space to help make sense of it all. In so doing I discovered an annoying feature that was causing my attempts to make a simple inclination correction script (for the first step of doing a rendezvous for eventual docking) fail. What was making it fail is that I calculated the normal vector to my plane of orbit, and the normal vector to my target's plane of orbit, and stored them ahead of time and assumed that it doesn't change until you start thrusting. Because they aren't supposed to change. The normal vector should be the same direction no matter where in the orbit you are.

But it was changing, becoming as much as 4-5 degrees off by the time I hit the ascending or descending node to make the burn. It was using the normal vectors to calculate the position of the node wrong and missing it. I wasted a lot of time trying to figure out what was wrong with my math, checking and rechecking and not finding a thing wrong with it.

In the end, it turns out that what was wrong was this: Between the time when I calculated the normals and several minutes later when I used them, KSP had rotated the universe a few degrees around the Y axis, effectively changing the direction that any previously calculated XYZ tuple is pointing. The direction that V(1,0,0) was pointing a few minutes ago was a few degrees off from where V(1,0,0) was pointing now. Therefore I couldn't use the mathematically correct assumption that the normal to your plane of orbit doesn't change. It does change in KSP, effectively, because the axes won't stay in a fixed orientation. Therefore the fix was to continually recalculate the normal vectors in a lock so when the universal reference frame rotates, I get new normal vectors using the new orientation.

I had the same problem when trying to draw vector arrows on the screen. I have to continually re-draw them because the damn universe keeps moving and rotating.

And it's the underlying KSP system that does this, so you'd get the same problem with all languages, not just KOS. You just need to be aware that any XYZ vector is only stable for a half a minute or so after you calculate it. If you need to read the vector and do something with it over a period of several minutes while you are drifting in orbit, you'd better keep regenerating it just in case the universe has rotated a bit.

I tend not to use R() rotations much but I suspect the same thing is true of them too, since they represent rotations from the Z axis direction, If you say this:

SET DIR TO R(30,0,0).

Then it's likely that a few minutes later DIR isn't pointing the same way it was before and it will be a few degrees different. Not enough to notice for crude operations but for precision operations (like trying to get the inclination down to less than 0.2 degrees) it matters and you need to make sure that DIR is a lock rather than a set.

To test what I'm talking about, get your ship into a Kerbin orbit that goes from a periapsis of about 80km to an apopasis of about 120km. Then at the apopasis, issue the command LOCK STEERING to V(1,0,0). Make note of where that points to relative to the navball's orbital prograde marker. Then timewarp a bit, then come out of time warp for about 30 seconds, then timewarp a while, then come out of time warp for about 30 seconds, and so on until you've make 3-4 orbits. Then wait until you get to exactly the apopasis again and look at what your LOCK STEERING TO V(1,0,0) is now doing. It will be pointing a little bit off from where it was before because the X axis isn't pointing the same way.

Edited May 15, 2014 by Steven Mading

[Dunbaratu]

I want to make a coordinate system document.

Months ago I wrote this up: http://kos.wikia.com/wiki/Tutorial_-_XYZ_system_of_KSP

I'd like to put equivalent information on the more official KOS_DOC pages, but in the meantime since I wrote that I've discovered a few other weird things that make it even more complex than I realized at the time, so I have to redo sections of that information.

I'd like to get user feedback on this:

(1) When learning to write kOSscript, what did (or still do) you find most confusing about the coordinates and directions that you feel really would have helped to have been documented?

(2) What support from kOS itself would have helped you, as a feature to add to the mod?

For (2), I'm already thinking that I'd like to provide direct conversions into different reference frames - for example a function call to transform XYZ vectors into an East,North,Up vector system, and visa versa (mostly useful for landing). Right now the only way to do it is with a block of matrix transformation math that you have to carry out manually in kosscript code. Another thing I'd like to see is a way to transform any rotation into a unit vector, and visa versa, with a single function call. (Both of these are, essentially, cases of moving matrix math into the mod itself where it can use the Unity API to do it more quickly, and in some cases Unity will farm out the matrix math to the hardware GPU to do it even faster).

[baloan]

I am forever annoyed that KSP keeps altering the XYZ frame of reference during play.

Maybe you fell victim to the changing frame of reference that happens in 100km altitude above Kerbin where KSP switches the origin from local ship reference frame to Earth reference frame. Below exactly 100km the moon reverses direction.

Sigh.

// display ship & mun coordinates
// note change in mun dv when ship is in kerbin orbit < 100km 
clearscreen.
set trgt to Mun.
until 0 {
    set pm0 to trgt:position - body:position.
    set ps0 to V(0,0,0) - body:position.
    wait 1.

    set pm to trgt:position - body:position.
    set ps to V(0,0,0) - body:position.
    set vm to pm - pm0.
    // print "Mun: " + pm.
    set pmu to (1/pm:mag)*pm.
    print trgt:name at (0,25).
    print "   P(" + round(pm:x/1000,4) + "," + round(pm:y/1000,4) + "," + round(pm:z/1000,4) + ")" at (0,26).
    print "|p|: " + round(sqrt(pm:x^2+pm:y^2+pm:z^2)/1000) at (30,26).
    print "Pbar(" + round(pmu:x,4) + "," + round(pmu:y,4) + "," + round(pmu:z,4) + ")" at (0,27).
    print "   v(" + round(vm:x,4) + "," + round(vm:y,4) + "," + round(vm:z,4) + ")" at (0,28).
    print "|v|: " + round(vm:mag) at (30,28).
    set ma to arctan(pmu:x/pmu:z).
    if pmu:z < 0 { set ma to ma + 180. }
    print "omg: " + round(ma,3) at (30,27).

    set vs to ps - ps0.
    // print "Ship: " + ps.
    set psu to (1/ps:mag)*ps.
    set sa to arctan2(psu:x,psu:z).
    if psu:z < 0 { set sa to sa + 180. }
    print "Ship" at (0,31).
    print "   P(" + round(ps:x/1000,4) + "," + round(ps:y/1000,4) + "," + round(ps:z/1000,4) + ")" at (0,32).
    print "|p|: " + round(ps:mag/1000) at (30,32).
    print "Pbar(" + round(psu:x,4) + "," + round(psu:y,4) + "," + round(psu:z,4) + ")" at (0,33).
    print "   v(" + round(vs:x,4) + "," + round(vs:y,4) + "," + round(vs:z,4) + ")" at (0,34).
    print "|v|: " + round(vs:mag) at (30,34).
    set sa to arctan(psu:x/psu:z).
    if psu:z < 0 { set sa to sa + 180. }
    print "omg: " + round(sa,3) at (30,33).
}

[marianoapp]

@baloan: I understand the advantages, but if you want to program in python and talk directly to kRPC then there's no need to use kOS. Our mod being more tightly integrated with KSP fills a different niche.

kOS is a computer that is IN the ship, you pause the game and the computer pauses too, if you loose power the computer shuts down. With kRPC you loose that, but as I said before is just a matter of preference.

Edited May 15, 2014 by marianoapp

[Ralathon]

Is there a way for kOS to detect what engine belongs to what stage when the engine is disabled?

Engines only seem to show up in "list engines." if they're enabled. But I'm writing a program that numerically tries to find the optimal gravity turn, and I need to detect different stages and their individual TWR's for that.

[gsmurf]

I think you need to delineate with a colon.

body:mun

I'm not sure though I've never done this before.

Unfortunately, I've already tried this and it does not work. The error returned is Suffix MUN not found on object. Thanks anyway.

Does anyone else have a suggestion on proper syntax?

[marianoapp]

I seem to be having a problem targeting planetary bodies.

The command set target to body("mun"). returns the following error: VESSEL 'BODY("Mun")' not found.

Has the syntax for targeting bodies been changed recently?

I am using the 12.1 prerelease.

Thanks.

Mmm that should work, I'll have to check it out. In the mean time you can use set target to "mun".

[Dunbaratu]

Mmm that should work, I'll have to check it out. In the mean time you can use set target to "mun".

set target to Mun:name.

Trying to make docking scripts possible is current top priority, if I understand erendrake correctly. One problem is how TARGET needs to work seamlessly on three different types of object: Bodies, Vessels, and Docking Ports. Frustratingly, although all three of those things share a common C# Interface in the KSP API called ITargettable, not everything about them that they share in common is inside ITargettable.

[Trekky0623]

Hi,

This is all new to me, but I have a question. Is there any way to write programs that return values? Like, say I want to write a program that calculates orbital velocity for a circular orbit at a given altitude. Can I run something like orbitv(100000) and have it return a value?

[Rosco P. Coltrane]

Hi,

This is all new to me, but I have a question. Is there any way to write programs that return values? Like, say I want to write a program that calculates orbital velocity for a circular orbit at a given altitude. Can I run something like orbitv(100000) and have it return a value?

Yes, kind of. You call the program and in that program you set a variable. All variables are accessible from any other program, so you can read it back from your original program. Like this:

//program_2
declare parameter Param1, Param2.
set p2_output to Param1 + Param2.

//program_1
run program_2(3, 5).
print p2_output.

//Will print 8.

[Vaporized Steel]

I'm sorry if this was asked before. I tried finding it on the first 5 pages on this thread and quite naturally wont analyse 77 pages for it.

But can this autopilot be set up so that you can navigate a wheeled rover?

I have 2 bases on the mun 200+ Km from each other.

And I would always liked a surface transport connection if however a transport could be automated.

If this mod is capable of doing so I can finally succeed in this transport connection if only the mod also allows such complex preset maneouvres on rover vehicles.

[erendrake]

can this autopilot be set up so that you can navigate a wheeled rover?

Yep! you can lock "wheelsteering" and "wheelthrottle" using kOS to drive rovers.

[Vaporized Steel]

That's great:D

Seems I got something to work on tommorow (couple of days perhaps )

[erendrake]

New version v0.12.1 is up

BREAKING: DOCKINGPORT:ORIENTATION is now DOCKINGPORT:FACING

* Fixed Terminal linewrap @ the bottom of the terminal
* Fixed "Revert to Launch" button, it was blowing up the world and not allowing control before
* Fixed LOCK s in subprograms
* Fixed RemoteTech integration blowing up everything
* Fixed flight controls not releasing when they should
* Disabled RemoteTech Integration while RT development is stalled 
* Fix exception when trying to type a multiline instruction in the interpreter
* srfprograde is available as a new shortcut
* BODY now has an OBT suffix
* Parts now have a SHIP suffix
* You can now work with your target if that target is a docking port
* Added a new PRESERVE keyword for repeating a trigger.
* all active triggers are removed when a script is finished.

[marianoapp]

Something I've been working lately, because developing kOS is fun but using it is even more fun!

[CaptainKipard]

That's damn cool, but how does the script run when the window says "Program ended"?

[Camacha]

Neat! Do you have some links or literature on APN?

[marianoapp]

That's damn cool, but how does the script run when the window says "Program ended"?

The program that ended is the one in the launcher, the missile is running a different program in its own core. The program in the missile is started by the launcher using the (still undocumented) "RUN ... ON ..." command that let you start a program in a different core.

Neat! Do you have some links or literature on APN?

These are some of the links I used while developing this: Intro, Advanced, Way too advanced (and math heavy)

Anyway most of real life complexities arise from errors in the measurements and in a bunch of others things that have to be compensated, and that we don't have to worry about .

[Dunbaratu]

(still undocumented) "RUN ... ON ..." command

I saw that in the source code but didn't document it because I hadn't heard any official announcement about it so I thought it was still under development and not ready for public mention yet.

Is it working well enough that I should mention it in the docs?

[marianoapp]

I wouldn't add it to the docs just yet, it still is very experimental and has its limitations (like not being able to pass parameters).

[Enceos]

Hello guys,

While using Remote Tech, I found a desperate need to preprogramm my probes before they go out of sight of my comm network. Seems like this mod will fill the gap perfectly. But do I have to tweak something so the commands sent by the k-OS script override the "No connection" remote tech status and actually make the probe do something while it is not connected to the Mission Control?

Edited May 22, 2014 by Enceos

[erendrake]

Hello guys,

While using Remote Tech, I found a desperate need to preprogramm my probes before they go out of sight of my comm network. Seems like this mod will fill the gap perfectly. But do I have to tweak something so the commands sent by the k-OS script override the "No connection" remote tech status and actually make the probe do something while it is not connected to the Mission Control?

The current RemoteTech/kOS integration is very beta right now. you can turn it on in the kOS config file and try it out. It should allow you to issue a command and the script will continue to run and function while you are out of range.

known issues include only having access to steering and throttle. No action groups or sas rcs toggles.

I have been holding off a bit to see where RT development goes and we have a lot on our plate already. That being said i see RT and kOS as the peanut butter and jelly of mods and i want them to work very well together