[1.3] kOS Scriptable Autopilot System v1.1.3.0

[MysticPing]

Getting clean cut readings for roll, pitch and heading remains an issue due to the weird KSP internal reference frame.

But you can get clean cut target heading. So why not vessel? It's the only missing piece in my program

[Xgkkp]

Is there a way to get a "Button" or control binding or something, so that I can, for instance hit "Hover" to have a script start taking control? Or do I have to load up the terminal and manually start it?

[Camacha]

But you can get clean cut target heading. So why not vessel? It's the only missing piece in my program

It just has not been implemented, possibly not yet. So many features, so little development time Personally I would like to see this too, but all in due time. As it stands, we are seeing many great futures being deployed in a relatively short timespan; the guys are doing a wonderful job.

Is there a way to get a "Button" or control binding or something, so that I can, for instance hit "Hover" to have a script start taking control? Or do I have to load up the terminal and manually start it?

You can set a script to load on boot. In that script you can define other scripts that need to load upon hitting whatever key you choose. However, boot is a tad broken at the moment, because KSP and kOS do not like craft with running kOS units to be saved. Reloading or reverting can cause weird things to happen.

[Dunbaratu]

Getting clean cut readings for roll, pitch and heading remains an issue due to the weird KSP internal reference frame.

That's what this was for:

ship:north gives you this Direction frame, for example:

Z-axis=north where your ship is. Y-Axis=Up where your ship is. X-Axis=East where your ship is.

ship:north:inverse * someRawVector

Gives you a new vector in which its X,Y, and Z axes now mean the east,up,north components of the original raw vector.

Alternatively you can use the dot product rule to transform any vector into a different rotational frame, like so:

If xbase, ybase, and zbase are 3 UNIT vectors in the current reference frame representing the basis vectors of a new rotated reference frame, you can obtain what the coordinates of a vector in that new frame would be by dot-producting it with them, assuming the new frame has the same handedness as the old (i.e. going from left-handed to right-handed requires more than just a rotation, but going from one left-handed system to another left-handed system, this works for).

vector's X coord in new frame = VDOT( xbase, rawVec ).

vector's Y coord in new frame = VDOT( ybase, rawVec ).

vector's Z coord in new frame = VDOT( zbase, rawVec ).

If you really need it as a degrees heading by the compass, then once you have those, use the new X and Z components with ATAN2 to derive the angle.

It might be nice to also have the navball data directly, but it doesn't exist yet, as this workaround functions for the time being, and there's bigger problems the 0.90 update caused that I'm looking at.

It is on the plan though to provide a better way, which I outlined in this github issue several days ago that I intend to get around to eventually implementing:

https://github.com/KSP-KOS/KOS/issues/440

(Warning, that's still in the 'talk about it' design phase - there's no guarantee it would really look like that in the end).

Edited December 27, 2014 by Steven Mading

[MysticPing]

o.O

I guess i'll have to look trough that carefully tomorrow. Looks very complicated.

[Trewor007]

There is this thing that bothers me with the partmodules:

example:

if i type: ship:parts[19]:modules[0]. i will get an answer: Bahaturret with is the 1 item on the list. so everything works. i get what i want.

so why if i want to go deeper (by that i mean looking/interacting with the fields in that module) i can't use:

print ship:parts[19]:getmodule[0]:allactions.

and have to use it like this:

print ship:parts[19]:getmodule("Bahaturret"):allactions.

why in one case kOS lets me use the number from a list, and in the other it demands a name?

[Dunbaratu]

why in one case kOS lets me use the number from a list, and in the other it demands a name?

ship:parts[19]:modules is not a list of actual partmodule objects. It's just a list of string NAMES of modules and that's all. This was deliberate because I wanted a means of getting a terse dump of the modules' names to come out. If each item in the :modules list was the whole module, then dumping that list to the screen would produce the full information of each module (it's list of KSPfields, KSPevents, and KSPactions), and thus not show you a terse list.

The only regret I have is in the naming of it. It should have been called modulenames rather than modules, to make this fact clearer.

[MysticPing]

snip

I admit. I'm completely lost. ELI5?

[Camacha]

I admit. I'm completely lost. ELI5?

I obviously missed some clues in Steven's video the first time I watched it, I am not done experimenting with the new features yet

[Trewor007]

Long story short:

Im trying to force a cooperation between BDArmory and kOS. But there are some problems due the nature of BDArmory.

http://forum.kerbalspaceprogram.com/threads/85209-0-25-BDArmory-v0-7-1-1-Dev-Thread-Dec-9?p=1635257&viewfull=1#post1635257

Armed with new knowledge i need to ask:

What is the closes thing in kOS to pushing a button?

is it toggling ligts, gears, breaks with will emulate( or not) pressing U,G,B.

Or maybe action groups? pushing numbers.

Or something else.

BTW:

Has anyone tried to transfer resources between tanks using kOS. I'm curios is that doable.

[Lorentz]

Long story short:

Im trying to force a cooperation between BDArmory and kOS. But there are some problems due the nature of BDArmory.

http://forum.kerbalspaceprogram.com/threads/85209-0-25-BDArmory-v0-7-1-1-Dev-Thread-Dec-9?p=1635257&viewfull=1#post1635257

Armed with new knowledge i need to ask:

What is the closes thing in kOS to pushing a button?

is it toggling ligts, gears, breaks with will emulate( or not) pressing U,G,B.

Or maybe action groups? pushing numbers.

Or something else.

BTW:

Has anyone tried to transfer resources between tanks using kOS. I'm curios is that doable.

you could use the ON command in combination with action groups. This is perhaps the easiest way for now.

[COLOR=#333333]ON[/COLOR] [COLOR=#333333]AG3[/COLOR] {
   [COLOR=#333333]PRINT[/COLOR] [COLOR=#DD1144]"Action Group 3 Activated!â€Â.[/COLOR]
}

[erendrake]

What is the closes thing in kOS to pushing a button?

It depends on how BDArmory is hooked up to that button. Are the actions you want available in the right click menu for the weapons you want to fire? because those buttons are available

BTW:

Has anyone tried to transfer resources between tanks using kOS. I'm curios is that doable.

Im pretty sure its impossible right now but it is on our list of items to add to kOS

[Trewor007]

It depends on how BDArmory is hooked up to that button. Are the actions you want available in the right click menu for the weapons you want to fire? because those buttons are available

That is the whole problem BDArmory has a fire button in a right click menu but its more of a place holder for some other peace of its code working in the background. And the button itself does not do anything even when click by user.

[Camacha]

That is the whole problem BDArmory has a fire button in a right click menu but its more of a place holder for some other peace of its code working in the background. And the button itself does not do anything even when click by user.

I think your installation might be having a problem, because when I boot up my 0.25 KSP installation with BDArmoury and push the fire (Toggle Turret) button in the right click menu, the gun fires. It seems to be a toggle though, so the first push fires (and a long push keeps on firing), the second push nothing happens, the third push reponds like the first one again.

Are you sure you are using the appropriate version of every mod for the right version of KSP? Since BDArmoury does not seem to be updated for 0.90 and all. It does seem to be more of a BDArmoury problem than a kOS problem in any case, so I guess continuing the discussion there would be more suitable.

[amiavamp]

I recently decided to take on the challenge of rescuing a kerbalnaut from orbit early in a career game without any upgraded buildings at the KSC. I concluded that my rescue ship would be guided by a probe core for its lower mass. I am using RemoteTech2, so the probe would have no connectivity except when over the KSC and would need to be guided by autopilot.

To this end, I wrote a kOS script to calculate a coplanar rendezvous. On my initial test run, I was astonished when it worked perfectly - a maneuver node was plotted that intercepted the target orbit at precisely the right location via a hohmann transfer. This maneuver node was simply for visualization purposes, and the script will be capable of performing the burn without the node to help it.

However, every other time that I've attempted to use the script, it fails in some way. Sometimes the intercept is not at the correct location, sometimes my probe and the target end up exactly opposite from one another, and sometimes the burn is set to an absurdly low deltaV value that doesn't go anywhere. I barely understand the math behind what I'm doing, and I eventually grew fed up with tinkering with code. So, I've come to ask for help.

This is the basic logic that the code follows:

The chaser ship is me.
The target ship is set to a specified vessel.

Get the semi-major axis of me and the target, then find the semi-major axis of the transfer orbit.

Get the altitude + planet radius for me and the target.

Calculate the angular velocity (radians per second) of me and the target.

Find the time of flight for the transfer orbit.

Find the phase angle I need to be at when starting the burn.

Find  the time until the burn starts.  If the wait time is negative (because  the spot is behind me), keep shifting forward full orbits until it  becomes positive.

Calculate the velocity and altitude I will be at when I start the burn.
Calculate the velocity and altitude I will be at when I intercept the target.

Find the deltaV needed by taking the absolute value of the velocity when I start the burn and when I intercept the target.

Mark the current time and add it to the time until burn so I have the time when it starts.

Determine if the burn is prograde or retrograde by comparing the semi-major axis of the transfer orbit and of the target's orbit.

Dump all of this onto another script that actually does the burn.

I don't expect anyone to go rifling through the actual script, but I do have some questions that would likely help me along.

1. Does a coplanar rendezvous require the orbits to be circular? I noticed that the script seems to grow more inaccurate as eccentricity increases, but this might be because of errors in calculation.

2. How do I properly find the phase angle between myself and the target? Right now, I'm using the law of cosines, and I seem to have problems if the phase angle is > 180.

3. I find the semi-major axis of the transfer orbit by adding the sma of me and the target, then dividing by 2. Is this right? Can I do the same for the semi-minor axis?

4. In order to find the velocity and altitude of the start of the burn and the intercept, I followed the post at http://www.orbiter-forum.com/showthread.php?t=26682. This involves find the orbital period, mean motion, mean anomaly, eccentricity, eccentric anomaly, true anomaly, and flight path just to get those two values. Is there a simpler way to find the velocity and altitude at a given point on an orbit?

5. Finding the eccentric anomaly involves iteration. My current code uses the "simple iterative method" from http://www.stargazing.net/kepler/kepler.html and normally takes 9 to 12 iterations. My original code took anywhere from 5 to 20 iterations. Is there a "best" way to find the eccentric anomaly?

6. How would I go about calculating the burn direction that would normally be given by a maneuver node (the blue dot)?

7. Should I have gone through all of this effort to save Matburry Kerman?

A big thanks to anyone who understands this mess.

[Dunbaratu]

Just a warning about upcoming releases.

(About KSP 0.90 career mode and the Building upgrades)

The current pre-release, and possibly the first 'real' release after that (i.e. the first release supported by CKAN) had as the goal "the minimum to get it to work in KSP 0.90 without breaking bugs".

When SQUAD introduced the limitations of building upgrades in career mode, they did it in a way that ONLY affects the user interface and not the underlying API that mods can call. That's why kOS 0.15.4.0 still lets you set maneuver nodes before you can do it manually in a career. This is not the *intent*. It's just that we haven't finished making kOS fully in agreement with KSP 0.90's new style of thinking.

KSO 0.90 hit us as a bit of a surprise. We knew there would be upgraded buildings and the like, but not that this would mean some of the data you can get from kOS would retroactively become a 'cheat'. For example, whether your script can call SHIP:OBT:NEXTPATCH or not really SHOULD depend on whether or not your tracking center has been upgraded to do patched conics, but at the moment it doesn't perform that check.

Of course, in a sandbox game, everything should work from the beginning - this is only for a career mode game.

I just wanted to mention this to help manage expectations, after seeing @amiavamp's post above. The ability to use kOS to set a maneuver node when your career game isn't supposed to be able to do that yet is a problem we do intend to fix eventually.

Edited December 30, 2014 by Steven Mading
The damn forum software merged my post upward when I needed it to be separate

[Xgkkp]

As a caveat to my answers, I haven't written my rendezvous script yet (having only just started playing with kOS in the past few days), but have been delving into the maths for my arbitrary-plane-orbit matching script (to fulfill the 'place x satellite' contracts).

Find the deltaV needed by taking the absolute value of the velocity when I start the burn and when I intercept the target.

I assume you are talking about total deltaV, because the deltaV needed at the node at the start of the burn is the difference between the initial velocity at the burn position, and the velocity of the transfer orbit at the burn position.

1. Does a coplanar rendezvous require the orbits to be circular? I noticed that the script seems to grow more inaccurate as eccentricity increases, but this might be because of errors in calculation.

2. How do I properly find the phase angle between myself and the target? Right now, I'm using the law of cosines, and I seem to have problems if the phase angle is > 180.

3. I find the semi-major axis of the transfer orbit by adding the sma of me and the target, then dividing by 2. Is this right? Can I do the same for the semi-minor axis?

4. In order to find the velocity and altitude of the start of the burn and the intercept, I followed the post at http://www.orbiter-forum.com/showthread.php?t=26682. This involves find the orbital period, mean motion, mean anomaly, eccentricity, eccentric anomaly, true anomaly, and flight path just to get those two values. Is there a simpler way to find the velocity and altitude at a given point on an orbit?

5. Finding the eccentric anomaly involves iteration. My current code uses the "simple iterative method" from http://www.stargazing.net/kepler/kepler.html and normally takes 9 to 12 iterations. My original code took anywhere from 5 to 20 iterations. Is there a "best" way to find the eccentric anomaly?

6. How would I go about calculating the burn direction that would normally be given by a maneuver node (the blue dot)?

7. Should I have gone through all of this effort to save Matburry Kerman?

1. As with an awful lot of the maths involved, the answer is "It doesn't have to be a circular orbit, but it makes things much much simpler"

2. You can get the true anomaly from the orbital parameters, and translate between the two orbits (a lot easier if you match planes first).

3. This sounds right - for a circular orbit, where the SMajorA == r. I'd assume it's possible for eccentrics, but you are no longer orbiting at the central point so it might be harder. Since you need the initial and final radii to calculate the velocities anyway, probably just easier (and less error prone) to use a_xf = (r_i+r_f)/2 (remembering to account for body radius).

4. As you have probably seen a reference to before - http://www.braeunig.us/space/ is a useful resource for this sort of thing, particularly http://www.braeunig.us/space/orbmech.htm (frustratingly spare on certain details, but certainly the best repository I have come across online thus far). Equations 4.43-4.45 are probably what you are looking for here, but again - with a circular orbit it is much simpler - the velocity and altitude are constant across the entire orbit. It might be worth getting the script working in the simplest case (circular) first, then elaborating it.

5. You only need to use iterative et al methods to go from mean -> eccentric anomaly, which you don't need to do because you have the true anomaly available. The above reference only gives the cosine part, which isn't enough to get a full value (arccos only gives the result in one quadrant). Following https://en.wikipedia.org/wiki/Eccentric_anomaly#From_the_true_anomaly, you can get the eccentric anomaly E from E = ARCTAN2(SIN(E),COS(E))

6. Don't completely understand the question, but if you have a maneuver node set up you can pull it's vector from kOS? Or, the blue handles that hang off the node? They are radial burns, so 90 degrees to prograde, in the plane of the orbit.

7. Hey, if you didn't want to really follow http://xkcd.com/1356/, then you would have just installed mechjeb and been done with it!

[Dunbaratu]

Let's brainstorm. Contract Ideas from YOU

If we added kOS contracts to the game for career mode, what contract conditions would be good?

(This is a post I ran by @erendrake first before I put it out here. You can consider it to be, essentially, from both of us.)

As it is, if you're playing career mode and you come up with a cool script, you get no credit for it - no funds, no science, and no rep. This means that effectively all your scripting tests really have to be done in sandbox mode only. This really should be changed so that roleplaying a space agency trying to experiment with autopilots and pay the expense of the testing program for them becomes a viable option.

So before we start designing potential approaches to this, we should really hear from you, the user community, about what contracts you think would be fun and what would not be fun.

We're interested in both ideas of single interesting contracts, and ideas of general contract-making strategies. Any opinion you have. This is brainstorming here, no ideas are final, and all ideas should be considered.

One general strategy I'm wondering about is whether the contracts should explicitly require computer control, or if they should just mention the applied goal, and we pick goals that would be really hard to try achieving by hand. (i.e. "fly due north for 20km, keeping your altitude between 3500m and 3505m the whole time. If you're insane enough to want to try doing that without an autopilot script you go right ahead and try.")

Contrast that with a contract like "obtain science from the mun with an unmanned craft, and without ever touching the manual controls after launch" - which would be a contract that does explicitly require the computer control.

A third option might be to take the existing contracts the game already has, and modify them to award an additional bonus if they can be accomplished without manual control. I do not know yet if this would be hard to implement. For one thing I haven't seen examples of 'optional' goals in the stock contracts system yet.

To get the ball rolling, here's some of my own I've been knocking around, along with a tag for whether I envision them as being early-game, mid-game, or late-game contracts.

• (early) land at Kerbin within a tolerance of location FOO, in which during the last 2000m of descent, all the following were true: No pilot controls, no parachutes are currently deployed. (you can manually pilot everything up to the last part and then have to let the software do the final landing, basically).
  
• (mid) Like the "land at Kerbin" above, but with much narrower tolerances, tight enough for things like "land on the helipad of the VAB" to work.
  
• (mid) stick a landing at location FOO on Mun (where FOO would be like the contract survey locations).
  
• (mid) Perform a surface scan mission (like the 'seismic surveys'), but once landed you cannot touch the controls directly - thus you have to autopilot drive the rover between the Alpha, Beta, and Gamma locations of the contract.
  
• (mid) hold altitude in a plane (as per description above). (only listed as "mid" because of the ridiculous fact that the stock game doesn't let you make airplanes in the early game).
  
• (late) Planetary transfer to another planet and back again, never touching the controls the whole time.
  

Okay I'll stop there. I have some other ideas but I should hold off because we want to hear ideas from YOU, not just rattle on about our own.

As of right now we haven't looked in extreme detail yet at what the contracts API will allow us to do and what it won't. But it looks quite flexible and I suspect it will let us specify quite a bit of unusual conditions.

Future plan:

This is all part of our upcoming desire to make a future release that fits the THEME of 0.90, and doesn't just merely WORK with it.

First there will be a full (not pre-) release soon, probably called 0.15.5, in which it has bug fixes for 0.90 compatibility but none of the thematic changes to make it FEEL like a 0.90 game now feels.

Then, Second, and much later, will be a release that adds the right stuff to thematically FEEL like 0.90 is supposed to feel, including checking for building upgrade tech levels before some stuff will work, and adding the aforementioned contracts, and so on.

Again, NONE of this is a promise - this is what we'd LIKE to do, not what we're CERTAIN we'll do.

So, let's see those contract ideas rolling in.

Edited December 30, 2014 by Steven Mading

[Xgkkp]

Contrast that with a contract like "obtain science from the mun with an unmanned craft, and without ever touching the manual controls after launch" - which would be a contract that does explicitly require the computer control.

I don't like, with current behavior, "no touching the controls" - too easy to accidentally break. I'm not sure if the computing unit acts like a probe core on it's own at the moment, but it could be made that it works as a core for ship/identification purposes, but with the caveat that when you have only the computing core (and no other probe core) none of the controls respond directly - like remotetech when there is no connection - with the only interface to control the craft being the terminal (direct commands, uploading scripts etc).

Then, the contract could specify the lack of any other control cores whilst fulfilling the conditions (e.g. if it was a landing contract, it would allow you to fly the probe to the destination as a payload manually, but not whilst you do the actual landing). That way the condition would be much more unambiguous.

[Dunbaratu]

I don't like, with current behavior, "no touching the controls" - too easy to accidentally break. I'm not sure if the computing unit acts like a probe core on it's own at the moment, but it could be made that it works as a core for ship/identification purposes, but with the caveat that when you have only the computing core (and no other probe core) none of the controls respond directly - like remotetech when there is no connection - with the only interface to control the craft being the terminal (direct commands, uploading scripts etc).

Then, the contract could specify the lack of any other control cores whilst fulfilling the conditions (e.g. if it was a landing contract, it would allow you to fly the probe to the destination as a payload manually, but not whilst you do the actual landing). That way the condition would be much more unambiguous.

The problem is that the computer unit isn't a probe core. If you have no probe cores, and no manual pilot capsules, and just the kOS computer, then KSP considers the craft to be debris. Probe cores can be made into kOS computers with ModuleManager rules, but going the other way and making a kOS computer into a probe core is a bit messier as there's multiple PartModules that a probe core has to have to function like a probe core.

I get what you're saying with a "don't touch the controls" condition being way too easy to fail by mistake: "Oops I forgot that the terminal window wasn't focused when I started typing, now those key presses count as manual piloting and I failed the mission", or "my fat fingers pressed the 'z' key when I meant to hit 'alt' ... now I failed the mission because that counts as manually controlling the throttle". There would need to be a better way to avoid that problem, you are correct.

Perhaps the way to avoid it would be to provide an actual manual lockout button on the terminal or in the KSP app launcher panel? As long as it's enabled then kOS will suppress all attempts to manually pilot until it's turned off again?

Or, alternatively, since we're bundling ModuleManager with kOS now anyway, maybe we can turn our kOS computers INTO probe cores with our own ModuleManager configs we ship with the mod? That way people would no longer have to include BOTH a probe core AND a kOS computer on their craft. Then the rule could be that you have to complete the mission using ONLY a kOS computer on the craft with no stock probe cores. (Then we could make it so that a kOS computer does not allow manual piloting, but does everything else a probe core does.)

These are just two ideas. Which works best will depend on experimentation. But I do get your point that "don't touch the controls" is just waaay to easy to fail by mistake or fat finger typing.

Okay, for the time being, for this and future suggestions in this thread, let's assume that we will use *one* of the ways mentioned above to solve that problem, so people can feel safe in adding "don't manually pilot" to their conditions of proposed contracts.

Edited December 30, 2014 by Steven Mading

[Camacha]

Or, alternatively, since we're bundling ModuleManager with kOS now anyway, maybe we can turn our kOS computers INTO probe cores with our own ModuleManager configs we ship with the mod? That way people would no longer have to include BOTH a probe core AND a kOS computer on their craft. Then the rule could be that you have to complete the mission using ONLY a kOS computer on the craft with no stock probe cores. (Then we could make it so that a kOS computer does not allow manual piloting, but does everything else a probe core does.)

I think that integrating kOS units into probe cores might hamper a couple of other ideas, like different disk sizes and processor speeds. It would making any distinction based on size impossible, and weight harder.

[Dunbaratu]

I think that integrating kOS units into probe cores might hamper a couple of other ideas, like different disk sizes and processor speeds. It would making any distinction based on size impossible, and weight harder.

I think you're reading what I said 100% backward. What I was suggesting in what you quoted of me was the other way around - Don't make probe cores gain the functionality of kOS computers, but make kOS computers gain the functionality of probe cores. This would allow you to build a craft that contains JUST a kOS computer and no stock probe core. Of course this is hypothetical anyway. I don't know if this is possible yet.

[Camacha]

Am I missing something? When I use:

list sensors in sens.
set sens[0]:active to true
print sens[0]:active.
print sens[0]:type.

I neatly get the message that the sensor is on and of the accelerometer type. However, I when I try to get a value:

print sens[0]:readout.

I get an error message: Get suffix type 'READOUT' not found on object. Can anyone confirm this or tell me where I am wrong?

I think you're reading what I said 100% backward. What I was suggesting in what you quoted of me was the other way around - Don't make probe cores gain the functionality of kOS computers, but make kOS computers gain the functionality of probe cores. This would allow you to build a craft that contains JUST a kOS computer and no stock probe core. Of course this is hypothetical anyway. I don't know if this is possible yet.

I am not sure how I feel about this, I must say I liked to separation between the two. It might be useful though.

Edited December 30, 2014 by Camacha

[Dunbaratu]

Am I missing something? When I use:

list sensors in sens.
set sens[0]:active to true
print sens[0]:active.
print sens[0]:type.

I neatly get the message that the sensor is on and of the accelerometer type. However, I when I try to get a value:

print sens[0]:readout.

That's due to incorrect documentation. There is no suffix called :readout. There is a :display but sadly it returns a STRING not a NUMBER, making it next to useless for scripting. There needs to be a numeric suffix added to it.

I get an error message: Get suffix type 'READOUT' not found on object. Can anyone confirm this or tell me where I am wrong?

I am not sure how I feel about this, I must say I liked to separation between the two. It might be useful though.

I'm not fond of the idea either. I'm just thinking of ways to solve the "detect that no manual control happened" condition for a contract, without penalizing you for accidentally tapping a key.

[Camacha]

That's due to incorrect documentation. There is no suffix called :readout. There is a :display but sadly it returns a STRING not a NUMBER, making it next to useless for scripting. There needs to be a numeric suffix added to it.

That would explain a lot. Does that mean there currently is no way of getting sensor data? That throws a spanner in my ascent script work

I tried getting it via the rightclick menu method, but that yields exactly the same result - and I guess that is the cause of the problem in the first place.