[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Buttons840]

If I launch with "lock steering to up." the ship usually tries to do a 180 degree roll and wobbles a bit. If I rotate the ship in the shipyard 180 degrees before I launch this does not happen. I also know you can do "lock steering to up + r(0, 0, 180)." or similar to prevent this problem.

Is there any way to detect the roll of your ship? I'd like to detect the roll of my ship and use that roll in maneuvers (especially launching) so my ship doesn't wobble around while rotating.

[Dunbaratu]

If I launch with "lock steering to up." the ship usually tries to do a 180 degree roll and wobbles a bit. If I rotate the ship in the shipyard 180 degrees before I launch this does not happen. I also know you can do "lock steering to up + r(0, 0, 180)." or similar to prevent this problem.

Is there any way to detect the roll of your ship? I'd like to detect the roll of my ship and use that roll in maneuvers (especially launching) so my ship doesn't wobble around while rotating.

Does anyone know if there is such a thing as "subtracting" a Euler rotation in kOS? Presumably if you want to know your current up-relative facing (the a,b,c in "up + R(a,b,c)") you could do it by getting your FACING and then...subtracting "up" from it? Would "facing - up" give you a rotation with the right starting frame of reference to be used in up + R(a,b,c) ?

[lagsalot]

You are welcome, this has been a fun project. Documentating these changes is my last step to getting the next release up and i am avoiding it by playing...wait for it....KSP

HAH... The true nemesis of all programmers, or anybody working on something technical, come to think of it. Documentation. ಠ_ಠ

[Buttons840]

For me, the "facing:roll" is always zero, and so is "heading".

[Dunbaratu]

For me, the "facing:roll" is always zero, and so is "heading".

Ah. Well then that is a problem. It's always possible to obtain any vector direction from just two rotations, so I guess that's how kOS is calculating the facing - it's probably deconstructing your vector direction into "what possible set of rotations would give me this direction" and solving for whichever one of the infinite number of rotation combinations that would give you that vector direction happens to be the one achieved by using a roll of 0. (In other words it's only paying attention to which way you're pointing, not how you are rolled around that axis.)

[Buttons840]

I have a small rocket that launches a satellite. I have two kOS "controllers" on the rocket initially, one on the rocket itself, and one on the satellite. What I would like to happen is have the rocket (the "lifter") carry the satellite into orbit, detach from the satellite, then burn retrograde so it wont become space junk; and I would also like the satellite to face a certain direction as controlled by kOS.

What happens though, is the satellite will be detached and the lifter will maneuver and burn retrograde (as controlled by kOS), but the satellite will not respond to steering commands, though I can toggle control groups with the kOS terminal [on the satellite]. Anyone know why this happens? Is the kOS terminal on the satellite still trying to control the detached lifter?

[togfox]

So has kos reached the point where a fully automated mun mission can be coded nasa style? Can kos do gravity turns, circularisation burns, determine transfer points, burn for x seconds etc.

I think the start and end parts of a mission like that is do able (go to orbit and land), but can kos determine burn points? Can it access the universe time so burn points can be preprogrammed?

[Dunbaratu]

So has kos reached the point where a fully automated mun mission can be coded nasa style? Can kos do gravity turns, circularisation burns, determine transfer points, burn for x seconds etc.

Look at the entries to this challenge thread:

http://forum.kerbalspaceprogram.com/threads/58068-kOS-The-Automated-Mission-Challenge/

They were made using older versions of kOS. If anything the stuff they do is a lot easier now in 0.11.

[Camacha]

I think the start and end parts of a mission like that is do able (go to orbit and land), but can kos determine burn points? Can it access the universe time so burn points can be preprogrammed?

Please consider that NASA is doing a lot of the calculative work on the ground, relaying it to the crews that have to perform the burns. Their work is incredibly complicated, but somewhat different from doing it all live during the flight

[Dunbaratu]

Please consider that NASA is doing a lot of the calculative work on the ground, relaying it to the crews that have to perform the burns. Their work is incredibly complicated, but somewhat different from doing it all live during the flight

True. Even on unmanned flights where there is no crew and the computer program runs the craft, it's usually configured to do something like "when your onboard clock says ....... then perform this maneuver", and the calculation for when that "...." is supposed to be was made by computers here on the ground and beamed to the craft.

I'm considering building a building-shaped "vessel" out of metal plates and girders for walls and "launching" it a short distance over to the KSP buildings and landing it there and leaving it there for all time. The building would have some SCS parts in it. The idea is that it would represent the home "mainframe" computer on the ground at mission control - so that the archive back home actually has a CPU that can execute things at home and send the results to the vessels. ("sending" values to the vessels via outputting self-modifying code "log" files that consist of nothing more than 'set' commands, that the vessels can copy and run.)

[Buttons840]

Ah. Well then that is a problem. It's always possible to obtain any vector direction from just two rotations, so I guess that's how kOS is calculating the facing - it's probably deconstructing your vector direction into "what possible set of rotations would give me this direction" and solving for whichever one of the infinite number of rotation combinations that would give you that vector direction happens to be the one achieved by using a roll of 0. (In other words it's only paying attention to which way you're pointing, not how you are rolled around that axis.)

I understand what your saying after reading up on Euler angles. You're saying kOS can describe my "facing" direction (ignoring rotation) using only 2 Euler rotations, and so the 3rd is never used? (And let me clarify that heading:roll is ALWAYS zero, is this just me, or a bug in 0.11?) Thank you for the explanation.

I would like to ask again, is there any way to figure out your ships rotation? I'm looking for a yes or no answer here. If there isn't a way, is it something we can hope for a future kOS versions? Or does it require a KSP change?

[EDIT: Changed some phrasing I realized might have come across as rude.]

Edited February 16, 2014 by Buttons840

[Camacha]

(And let me clarify that heading:roll is ALWAYS zero, is this just me, or a bug in 0.11?)

As far as I know that has always been this way. I have had a little fun with that a little while ago (I think with 0.7).

[kaesekuchen]

The "roll" component of print ship:facing will always return 0 because the ToString() returns this:

 "R(" + Math.Round(euler.x, 3) + "," + Math.Round(euler.y, 3) + "," + Math.Round(euler.z, 3) + ")";

You can test this yourself with this little debug kOS script:

print "debug : ship:facing:roll range".

set minRoll to 9999.
set maxRoll to -9999.

set rollSteer to 0.
set sas to false.

lock steering to r(0,0,0).
wait 1.

until rollSteer > 360
{
lock steering to r(0,0,rollSteer).
wait 0.5.
set minRoll to min(minRoll,ship:facing:roll).
set maxRoll to max(maxRoll,ship:facing:roll).
set rollSteer to rollSteer+15.
}

print minRoll.
print maxroll.

This script should return 2 very small numbers that are > 0 or < 0.

We probably have to look into this, to achieve that the roll component of the ship:facing direction will actually contain usable data for "lock steering to..." commands.

[Buttons840]

It could be related that heading always returns a very small number (like n * 10 ^ -7 small, where n is some integer). I always thought such small number were just a rounding error in the game. Is that the case?

[Dunbaratu]

Blaming the rounding for the problem is gettting it backward, I think.

Imagine this: You are rolled 80 degrees from the horizon according to the navball (so pulling "up" with the "S" key turns you is nearly east, and your the "W" "down" key turns you nearly west.)

When you "print facing:roll" you get a value of 0.0001.

When you "print facing" you get a value of R(102.812,50.012,0).

We don't care about the printing display being 0.0001 off from the value of the variable. We care about the value of the variable being 79.9999 off from what we'd expect in the first place, before the rounding happens.

If you do try to address this, please take care to make sure you test it using a craft that is NOT in an equatorial orbit. Make sure it's in a highly inclined orbit and you test the result at different latitudes throughout the orbit. This is because the equator is the XZ plane of the coordinate grid, such that errors involving flipping of axes, or using the wrong axis can easily go unnoticed near the equator where the errors from those sorts of mistakes often don't manifest. I've made lots of errors about this in some of my earlier code because of that.

[togfox]

So after many weeks working on a Terrain Avoidance System, I have finally made a crude demonstration that it can work.

Terrain Avoidance System

I need to adjust it for a lander 'falling' from a high orbit, and then test it out on different bodies. I welcome all comments, encouragement, refined code, better algorithms or anything else that will help my unattended probes land on foreign and unexplored lands.

[Zander]

Hey,

can you tell me where the command reference for the new .11 is?

I used to be able to use "print sensor:acc:mag." but now that returns an error.

where is the full list of commands for the new version?

I want to be able to know how to get the current acceleration of the craft from the accelerometer sensor.

Edited February 17, 2014 by Zander

[kaesekuchen]

The sensor suffix has been renamed to "sensors".

So instead of "print ship:sensor:acc:mag" you have to use "print ship:sensors:acc:mag"

[sarkun]

So great that we have progress on kOS! I'd very much like to get back to coding my missions will try this after I get home from work.

[erendrake]

Hey,

can you tell me where the command reference for the new .11 is?

I used to be able to use "print sensor:acc:mag." but now that returns an error.

where is the full list of commands for the new version?

I want to be able to know how to get the current acceleration of the craft from the accelerometer sensor.

Sorry about that change, I getting ready for addons to be able to add their own sensors so i wanted that member to be pluralized. That was compounded by not being in the changelog. My bad.

Btw the new Reference document site is up

http://erendrake.github.io/KOS/

Let me know what you think.

[Izandral]

I tried making a landing prog a couple of months ago but ran into problems because there was no surface prograde value. has this been added ?

[Wylde]

Is it possible to make a webpage from where you can send the commands / write the scripts? Anyone knows anything about this ?

[erendrake]

Is it possible to make a webpage from where you can send the commands / write the scripts? Anyone knows anything about this ?

You can use an external text editor to edit any file in your archive.

There is no external terminal.

[Dunbaratu]

I tried making a landing prog a couple of months ago but ran into problems because there was no surface prograde value. has this been added ?

There is no surface prograde Direction (i.e. Euler Rotation tuple) but there *IS* a surface velocity Vector which when you think about it contains almost all the same information. (It's missing "roll" information, but adds magnitude information.)

And you can lock steering to a Vector just as easily as locking it to a Direction.

For example, for retro-firing you can keep yourself pointed at surface retrograde by simply doing this:

lock steering to (-1) * velocity:surface.

and that *should* be almost identical to:

lock steering to retrograde:surface.

(If there was such a thing as retrograde:surface).

The only difference, really, might be your roll angle. Both will point you at the same spot on the navball.

For a simple crude lander script, that should be enough, provided you don't try to kill your speed all the way to zero. As long as you try to keep descending at 5-6 m/s or so, then just locking to negative surface velocity should steer you fine. (It starts to break down if you want to hover, since as your vertical velocity starts to get near zero, the surface vector direction will get very 'sideways' and 'swingy' and staying locked to it when it does that would be suicidal. When I wanted to make a hover and seek-for-better-terrain algorithm, I had to do something more complex than just locking to retrograde. But as long as you're not trying to do that, locking to retrograde is fine.)

Edited February 17, 2014 by Steven Mading

[Dunbaratu]

Btw the new Reference document site is up

http://erendrake.github.io/KOS/

Let me know what you think.

Is it an editable file on the github (meaning people can try to edit it and those edits would reach you in the form of pull requests for you to accept or reject)? Fixing up documentation is one of the places where community help can really help a lot because it's far easier to tell that the documentation has a problem if you're in the process of actually trying to learn from it than if you're the person who wrote it and already knows what it was supposed to mean.

I think the documentation being an editable github thing might be a good compromise between no user input to the documentation versus documenting by Community Wiki (Which has the problem that people can make up stuff that's wrong and not realize it's wrong because the actual author isn't involved to approve changes).

Anyway, thank you for putting documentation out.

Question 1 - about the Direction documentation:

I'm going through it and I noticed that you mentioned VECTOR as one of the fields of the Direction structure. What is that? Does it return a unit vector in the direction of the Direction?

Question 2 - about the List documentation:

Is there some way to obtain random access to a single element from a list at its Nth position for any arbitrary N, rather than having to iterate over it sequentially in a FOR loop to get to it? Basically, is there an index operator like:

print "The thing at index 3 is " + things[3].

or

print "The thing at index 3 is " + things:atindex(3).

or

print "The thing at index 3 is " + ListElement( things, 3 ).

If there is an operator like that, the documentation doesn't seem to mention it. (And if there isn't, it would be a really good idea to add it.)

Maybe its the thing called "ITERATOR" that does it, but if so it's not mentioned how to use it anywhere on the page.

Edited February 17, 2014 by Steven Mading