[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Kerbin- We have a problem]

It doesn't break anything, but there's no integration. Someone would have to write a plug-in to get RPM to interact with kOS.

yeah good point

[Kerbin- We have a problem]

Does anyone have any pre-made codes

[Drew Kerman]

see my sig for two. there was a repository site under development by another user but that has stalled

[Entropius]

Does anyone have any pre-made codes

I have a script that executes your next maneuver node.

It seems pretty reliable, like 95% of the time, but on rare occasion it fails to start the engine burn at all and just ends early. I'm not sure why, and if it's due to a bug on my end, or kOS's. (If anybody has any insight into that, I'd love to hear it).

EDIT: I just realized in my code there's a comment warning that it doesn't work with thrust limiters, but it actually does handle those now, so disregard that line.

Edited September 24, 2014 by Entropius

[Kerbin- We have a problem]

I have a script that executes your next maneuver node.

It seems pretty reliable, like 95% of the time, but on rare occasion it fails to start the engine burn at all and just ends early. I'm not sure why, and if it's due to a bug on my end, or kOS's. (If anybody has any insight into that, I'd love to hear it).

EDIT: I just realized in my code there's a comment warning that it doesn't work with thrust limiters, but it actually does handle those now, so disregard that line.

thanks a lot!

[Drew Kerman]

It seems pretty reliable, like 95% of the time, but on rare occasion it fails to start the engine burn at all and just ends early. I'm not sure why, and if it's due to a bug on my end, or kOS's. (If anybody has any insight into that, I'd love to hear it).

I'd suggest using the burn equations I have in my RCS Thrust Controller script (see sig). That way you can simply burn by exact time needed rather than using the node dV to tell when you are done.

[Entropius]

I'd suggest using the burn equations I have in my RCS Thrust Controller script (see sig). That way you can simply burn by exact time needed rather than using the node dV to tell when you are done.

My script actually does calculate the burn-time, it just doesn't solely rely on burn-times alone. This is because when I did rely on burn-times alone, I'd randomly run into problems where on extremely rare occasions, the script would fail to end on the designated time, and burn until I killed the script. So I added 2 criteria for ending: (1) timing out or (2) overshooting the ∆v and seeing it increase (a redundancy/fail-safe). Maybe I just have to either accept rare cases of over-burns or no-burns.

EDIT: I take that back, I don't actually rely on timings to end the script (just when to begin the burn), you're right that it's looking to ∆v. My memory fails me yet again… Anyway, if I use strictly JUST timing to end it, I'm not sure how I'd know when to do the slow-burn throttle, which would seem important since a very high-thrust engine may overshoot the target a bit if at full throttle.

Maybe I'll play with it a bit, but ultimately I'd still like to figure out why the current approach randomly fails, even if another approach might work.

Edited September 25, 2014 by Entropius

[Entropius]

@Kerbin, We Have a Problem, as per Gaiiden's suggestion, here's an alternative version that relies purely timing for ending the burn.

http://pastebin.com/skBnC7fH

Since it doesn't throttle down slowly near the end, you're going to have to make sure the burntime isn't too short on small maneuvers. If it is too short, use a thrust limiter to force the burn to take longer.

[Kerbin- We have a problem]

@Kerbin, We Have a Problem, as per Gaiiden's suggestion, here's an alternative version that relies purely timing for ending the burn.

http://pastebin.com/skBnC7fH

Since it doesn't throttle down slowly near the end, you're going to have to make sure the burntime isn't too short on small maneuvers. If it is too short, use a thrust limiter to force the burn to take longer.

K Thanks everyone!

[Drew Kerman]

Anyway, if I use strictly JUST timing to end it, I'm not sure how I'd know when to do the slow-burn throttle, which would seem important since a very high-thrust engine may overshoot the target a bit if at full throttle.

Since it doesn't throttle down slowly near the end, you're going to have to make sure the burntime isn't too short on small maneuvers. If it is too short, use a thrust limiter to force the burn to take longer.

Yup, that's exactly what needs to be done with the time method. Smaller the maneuver, smaller the thrust to extend the burn over a longer period of time for better accuracy. Which is why my RCS Thrust Controller allows the user to define how much thrust to use. Altho - looking at your code and seeing that you can read the thrust limiter, I think I will change it to just use that rather than an input parameter.

Thanks for the trade

[Trewor007]

Hi.

I'm writing, a rover script, and i would like to ask if there is a method to check the status of the wheels. I want to check them if they are broken so i can stop the rover if that value is true.

[erendrake]

Hi.

I'm writing, a rover script, and i would like to ask if there is a method to check the status of the wheels. I want to check them if they are broken so i can stop the rover if that value is true.

There is not, Its a good idea to add this kind of data.

[madlemur]

There is not, Its a good idea to add this kind of data.

Periodically count the wheels. If the count goes down, one or more are broken.

[Dunbaratu]

Periodically count the wheels. If the count goes down, one or more are broken.

3 good wheels plus 1 broken wheel is still 4 wheels.

[dzikakulka]

Is there any actual documentation on ModuleWheel ParModule ? Like if there is any easily accesible boolean if it's broken or not and how is it handled?

[Camacha]

There is not, Its a good idea to add this kind of data.

Might it somehow be possible to detect rotational speed of separate wheels? Not only would this enable you to detect broken wheels, you might also build more complicated things like ABS - though you might also need individual wheel control for some fancy complex wizardry.

[madlemur]

3 good wheels plus 1 broken wheel is still 4 wheels.

True, but three wheels when you started with four means one is definitely broken (off)...

[dzikakulka]

True, but three wheels when you started with four means one is definitely broken (off)...

I think Steven meant that a broken wheel is stil a wheel.

[Drew Kerman]

Hi.

I'm writing, a rover script, and i would like to ask if there is a method to check the status of the wheels. I want to check them if they are broken so i can stop the rover if that value is true.

You will be able to do this eventually, as kOS is adding the ability to read right-click menu properties, such as in this case whether a wheel is broken

[Wercho]

Two things:

I've been hit hard by the half-your-ship-doesn't-load bug since kOS 14, so I switched back to 13.1 for the time being. One thing I noticed with 14 is that I'd get the failure to load when landed or almost landed on the Mun, but not while in orbit of it. Even sub orbital flights load just fine, as long as I'm above roughly 5,000 or 6000 meters. Above that altitude, I seemed to be able to save and load without any issues. I didn't test on any other celestial bodies, so I'm not sure if this is specific to the Mun or not.

Second, I've noticed an incompatibility between 13.1 and AGX (Action groups extended) 1.17, where AGX is blocking the default action groups, causing them to be not registered in kOS ("ON AG1" type calls). Diazo asked what KSP variables kOS is using so that maybe he can make a quick fix. I know that a big compatibility thing is in the works, but this would just be short term I think.

Quote from Diazo:

AGX is an action group manager and so replaces the default KSP action groups and manages the actions directly. At the moment that means the KSP default groups never change state as AGX is taking care of it. Do you know which variable kOS is looking at? I can probably go ahead and set that for compatibility.

[foma87]

Hi there,

I´m trying to define a variable x with multiple values. Example:

x1 = 23

x2 = 372

x3 = 5

x4 = 17

...etc.

I know I can create a list like this:

set x to list().

set x:add to 23.

set x:add to 372.

set x:add to 5.

set x:add to 17.

...etc.

In this case, I could get the value of x2 like so:

print x[1].

My question now is,

is it possible to create a list with values without using that much code. I could see the script getting huge if I try to make a list with lots of values.

Something that could look like this maybe?

declare variable x (x1, x2, x3, x4...etc.).

Any help is appreciated.

[Dunbaratu]

is it possible to create a list with values without using that much code. I could see the script getting huge if I try to make a list with lots of values.

Not at the moment, but it is a good idea to take under advisement. A lot of languages let you fill arrays with a syntax a bit like this:

v = {23, 371, 5, 17}.

maybe kOSscript could be modified a bit to support something a bit similar.

[foma87]

Yes, that would come in really handy.

I wanted to have two lists:

One with altitude-benchmarks and one with velocity-benchmarks in order to calculate the optimal acceleration for a given altitudeframe. Example:

//from 0 to 1000 meters:

g0 = 9.81

v[x] = 0 (starting velocity)

v[x+1] = 110 (final velocity)

alt[x] = 0 (starting altitude)

alt[x+1] = 1000 (final altitude)

//from 1000 to 2000 meters:

v[x] = 110

v[x+1] = 124

alt[x] = 2000

//optimal acceleration given the above variables

acc = (v[x+1]^2-v[x]^2/2*(alt[x+1]-alt[x])+g0.

I resorted to adding the benchmarks manually to the lists. Although that did mean I had to cut the benchmarks from 14 to 4 for each list, since I`m too lazy and it visibly overloads the script.

Thank you for your answer nonetheless!

[foma87]

I have come across another problem. Is there a way to create a list within a conditional statement like <when>?

I would like the script to recalculate the total isp of multiple engines which get active immediately after a staging event.

Right now, the script looks like this:

set x to 0.

set y to 0.

set isplist to list(). //list of engine isps

set thrlist to list(). //list of engine maxthrusts.

set thrtot to 0.

set thrisp to 0.

list engines in e.

when altitude<0 then {

for eng in e

{

if eng:ignition="true"

{

set isplist:add to eng:isp.

set thrlist:add to eng:maxthrust.

}.

}.

until thrlist:length=x

{

set thrtot to thrtot+thrlist[x].

set thrisp to thrisp+(thrlist[x]/isplist[x]).

set x to x+1.

}.

set isp to thrtot/thrisp.

print "Cummulative ISP: "+isp+" sec".

}.

What this script is first to add up all the values from thrlist and then to divide the value in thrlist[0] by the value in isplist[0]. Then the value in thrlist[1] by the value in isplist[1]....etc.

At the end, <thrtot> gets divided by <thrisp> to get the isp.

However, when my condition is met I get this error message:

Tried to push Infinity into the stack.

At <script> on <volume>, line <number>.

set thrisp to thrisp+(thrlist[x]/isplist[x]).

Note that the script works when I´m not using a conditional statement and have ignited engines.

[undercoveryankee]

I have come across another problem. Is there a way to create a list within a conditional statement like <when>?

I would like the script to recalculate the total isp of multiple engines which get active immediately after a staging event.

It's possible that you have an engine in your list that reports ignition=true and reports zero isp. An engine that has flamed out will have ignition=true, flameout=true. When your condition is met, are any of your engines flamed out? This can include engines in dropped stages, if they were attached to the ship when you did the list engines and the debris is still in existence. You'll want to re-list engines at the top of the when block if you've dropped engines, and you'll want to check flameout as well as ignition when you're checking for active engines.