Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0


erendrake

Recommended Posts

PLZ FIX, there seems to be issues with scripts that have names with numbers, gives me big fat error when my script is 1.ks, but demo.ks works fine.

There is a warning about this in docs, all script names should obey the variable-naming rules, i.e. should start with a letter.

http://ksp-kos.github.io/KOS_DOC/commands/files.html?highlight=run#important-exceptions-to-the-usual-filename-rules-for-run

Link to comment
Share on other sites

Hey Guys,

i have a little more general question, but i think it fitts in here.

I try to write a script, that makes me a manuver node for circularisation.

I calculate the velocity for a circular orbit in that hight and so on.

Then i set the node at the apoapsis with the proper deltav.

But periapsis and apoapsis of the node differ for about 10 km......

i can compensate this either by adding a radial amount of velocity, or by shifting the node in time.

then it is nearly circular (error is not more than 1 km)

so for me it seems, that there is a problem with setting the manuver node time correct, because an impuls at the apoapsis should not add radial components, right?

and manuver nodes are calculated as an impuls like change in velocity as far as i know

But it doens't seem to be a problem of kos alone; i get the same error, when i set the node to apoapsis via precise node.

Can someone else confirm this problem, or is it a problem somewhere with my install?

perhaps it is a numeric problem?

Link to comment
Share on other sites

Hey Guys,

i have a little more general question, but i think it fitts in here.

I try to write a script, that makes me a manuver node for circularisation.

I calculate the velocity for a circular orbit in that hight and so on.

Then i set the node at the apoapsis with the proper deltav.

But periapsis and apoapsis of the node differ for about 10 km......

i can compensate this either by adding a radial amount of velocity, or by shifting the node in time.

then it is nearly circular (error is not more than 1 km)

so for me it seems, that there is a problem with setting the manuver node time correct, because an impuls at the apoapsis should not add radial components, right?

and manuver nodes are calculated as an impuls like change in velocity as far as i know

But it doens't seem to be a problem of kos alone; i get the same error, when i set the node to apoapsis via precise node.

Can someone else confirm this problem, or is it a problem somewhere with my install?

perhaps it is a numeric problem?

Post your code here, we'll try to analyse it and help.

Link to comment
Share on other sites

What value is it that you want to check? All variable-types in programing have an some type of limit. So dividing a number by a infinitesimally small number will never return anything useful.

Most floating point representations do in fact have a "magic" value that means infinity.

http://en.wikipedia.org/wiki/IEEE_754-1985#Representation_of_non-numbers

kOS doesn't support testing for any of them, even though some of its math functions do return Infinity in some cases - such as to represent holes in domain space for functions like TAN() and LN().

For infinity, I'd just check if it's bigger than a really big number.

For checking isNaN, on the other hand... well that's a thing the language could use, in my opinion.

Link to comment
Share on other sites

I will post my code as soon as i come home, thanks for the offer

But i doubt that you will find anything, because it also happens when i set the manouver node with "precise node" to apoapsis

Well it is not a Problem, i am ging to write a short approximation to deal with that Problem.

I am just curious if somebody has the same Problem:-)

Edited by BlueTiger12
Link to comment
Share on other sites

Could I offer a challenge to anyone to develop a KOS script capable of lifting this space shuttle into 200km orbit assuming the correct fuel amounts are loaded by the player, and to automatically adjust its flight profile depending on the cargo weight between 0 and 42 tons maximum? Then a landing script with an empty shuttle bay?

Craft File Thread and Download:

http://forum.kerbalspaceprogram.com/threads/108219-STS-4-Space-Shuttle-%28Stock-NASA-Replica%29-New-User-Subs-TRS-and-MMU-New-Video!-4-13-15

Link to comment
Share on other sites

Post your code here, we'll try to analyse it and help.

This i my code:


// known state
sas on.
wait 1.
sas off.
rcs off.
set tval to 0.


set G to 3531600000000/BODY:MASS.
set a to (BODY:RADIUS + (APOAPSIS + PERIAPSIS)/2).
print a.
set da to max(0.001,maxthrust/mass).


set runmode to 31.


until runmode = 0
{
if runmode = 31// get manuver node
{
// set v1 to sqrt(G * (BODY:MASS + SHIP:MASS) * ((2/(APOAPSIS + BODY:RADIUS)) - (1/a))).
set v1 to velocityat(ship, time:seconds+eta:apoapsis):orbit:mag.
set v2 to sqrt(G * (BODY:MASS + SHIP:MASS)/(BODY:RADIUS + APOAPSIS)).
print v1.
print v2.
set deltav to v2 - v1.
set node1 to NODE(TIME:SECONDS + ETA:APOAPSIS, 0, 0, deltav).
add node1.
set burntime to node1:deltav:mag/da.
print burntime.
if nextnode = node1
{
set runmode to 32.
}
}
else if runmode = 32
{
set warp to 3.
if node1:eta < burntime + 60
{
set warp to 0.
set runmode to 33.
}
}
else if runmode = 33
{
lock steering to node1:deltav.
if node1:eta < burntime + 1
{
if node1:deltav:mag > 2*da
{
set tval to 1.
}
set runmode to 34.
}
}
else if runmode = 34
{
if (node1:deltav:mag < 2*da)
{
set tval to min(1, node1:deltav:mag / da).
}
if (node1:deltav:mag / da) < 0.1
{
wait 0.1.
set tval to 0.
remove node1.
set runmode to 0.
}
}


if (STAGE:SOLIDFUEL < 1) and (SHIP:SOLIDFUEL > 0)
{
wait 1.
}
if (STAGE:LIQUIDFUEL < 1) and (SHIP:LIQUIDFUEL > 0)
{
wait 1.
}
lock throttle to tval.
}

Manuver Node is generated in runmode 31.

The script should be capable of circularizing any orbit around kerbin.

Thanks for looking over it.

Link to comment
Share on other sites

My calculation code is a bit different, but it was created before velocityat was added

I can create almost perfect circular orbits with it.

I think problem with your code are due to velocityat being calculated while ship is still in atmosphere, which gives wrong velocity.


declare parameter alt.
// create maneuver node at apoapsis which sets the orbit to alt.


set vom to velocity:orbit:mag. // actual velocity
set r to body:radius + ship:altitude. // actual distance to body
set ra to body:radius + ship:obt:apoapsis. // radius in apoapsis
set va to sqrt( vom^2 + 2*body:mu*(1/ra - 1/r) ). // velocity in apoapsis
set a to ship:obt:semimajoraxis. // semi major axis present orbit
// future orbit properties
set r2 to body:radius + ship:obt:apoapsis. // distance after burn at apoapsis
set a2 to (alt + 2*body:radius + ship:obt:apoapsis)/2. // semi major axis target orbit
set v2 to sqrt( vom^2 + (body:mu * (2/r2 - 2/r + 1/a - 1/a2 ) ) ).
// setup node
set deltav to v2 - va.


set nd to node(time:seconds + eta:apoapsis, 0, 0, deltav).
add nd.


Link to comment
Share on other sites

Hmmmmm

But my nodes also differ when i run this from a not circular orbit (so out of the athmosephre)

also on ascend i run this script after passing 70000 meter

And when i drag the node i get a circular orbit, so i think the amount of deltaV is right.

But the timing the node gets set seems to be wrong.

- - - Updated - - -

for example:

atm i try to create a node for an orbit that differs for about 5 km

mechjeb makes a perfect circular orbit

but my script only makes a orbit that differs for about 90 meter.

i am wondering where that problem comes from

i created a little iteration to deal with my problem

if anyone wants to use it, or is just interested:


DECLARE Parameter epsilon. // Abort Error
DECLARE Parameter delta. // starting width
CLEARSCREEN.


// calculate initial error
set error to nextnode:ORBIT:APOAPSIS - nextnode:ORBIT:PERIAPSIS.
print error.
set lasterror to 0.
set h to 1. // iteration width
set i to 0. // number of iteration
until (error <= epsilon)
{
// if error not reached in 1000 iterations, give up
if i > 1000
{
print "Sollution not possible".
break.
}
// if overshooting, reverse and make h smaller
if error >= lasterror
{
set h to (-1 * delta * h).
}
// setting values
set time1 to (nextnode:ETA+time:seconds).
set nextnode:ETA to time1-h-time:seconds.
set lasterror to error.
set error to nextnode:ORBIT:APOAPSIS - nextnode:ORBIT:PERIAPSIS.
set i to i+1.
// printing
print "Iteration: " + i at (5,4).
print "Step: " + h at (5,5).
print "ETA: " + nextnode:ETA + " " at (5,6).
print "Error: " + error + " " at (5,7).
}


first parameter is the error you tolerate (shouldn't be smaller than 1; best chances with 5)

second parameter is the starting width of the iteration (0.9 seems to work really well)

after 1000 iterations it will give up.

!! and it only works for a circularisation burn, with the exact amount of deltav for a circular orbit at that hight !! ;-)

still, if somebody has an idea what causes the problem, i would be very interested

------edit----

and, i don't know why, but the iteration seems to work best, the sooner it is executed after creating the node....

Edited by BlueTiger12
Link to comment
Share on other sites

Kerbin...we have a problem.

Is kOS compatible with KWRocketry? SHIP:LIQUIDFUEL and STAGE:LIQUIDFUEL return the same values. This seems to only happen with my rocket that is made with all KWRocketry parts. Stock parts will return their proper values. Should I be posting this in KWRocketry forum? They return the proper values when its on the launch pad but as soon as the stage kicks in (after boosters) they will both return SHIP:LIQUIDFUEL...

cmOwKLP.png

Edited by Smokie23
Link to comment
Share on other sites

The panel shows the same value. Same values are displayed also when I check "stage only" box.

Once upon a time kOS had its own homebrewed code for calculating the stage values. Then this was scrapped in favor of calling KSP's own API method for it, as it was assumed this would be more future-compatible with whatever SQUAD chooses to do later.

But the problem? KSP's own API routine returns baffling results that make no sense in some cases. There's a chance we'll have to go back to doing it in homebrewed code.

Link to comment
Share on other sites

Kerbin...we have a problem.

Is kOS compatible with KWRocketry? SHIP:LIQUIDFUEL and STAGE:LIQUIDFUEL return the same values. This seems to only happen with my rocket that is made with all KWRocketry parts. Stock parts will return their proper values. Should I be posting this in KWRocketry forum? They return the proper values when its on the launch pad but as soon as the stage kicks in (after boosters) they will both return SHIP:LIQUIDFUEL...

http://i.imgur.com/cmOwKLP.png

I had this exact problem. The solution (that another suggested) was to instead stage when the current SHIP:MAXTHRUST < the maxthrust at the beginning of the stage.

Here is some example code:



SET maxT to MAXTHRUST. //remember max thrust for staging.

//program foo.

IF MAXTHRUST < maxT {
LOCK throttle to 0. //Prepare to stage.
WAIT 3.
STAGE.
SET maxT to MAXTHRUST. //Re-initalize maxT.
WAIT 2. //Wait for stage seperation.
LOCK throttle to 1.
}

EDIT: I should probably note that this logic assumes you will have an engine activated for every stage of the program, and that you won't be using engine-less drop tanks. The program merely assumes that if the MAXTHRUST of the craft has dropped then some engines must be out of fuel. I also haven't tried it with fuel breathing SSTO's, though I think it SHOULD work for them with a little re-purposing.

Edited by Blu_C
Link to comment
Share on other sites

Once upon a time kOS had its own homebrewed code for calculating the stage values. Then this was scrapped in favor of calling KSP's own API method for it, as it was assumed this would be more future-compatible with whatever SQUAD chooses to do later.

But the problem? KSP's own API routine returns baffling results that make no sense in some cases. There's a chance we'll have to go back to doing it in homebrewed code.

Yes, its very weird. It almost like it depends on the ship setup. Made a new rocket with KW parts and the stock panel now returns proper stage and ship values but the kOS return values for SHIP:LIQUIDFUEL and STAGE:LIQUIDFUEL on the launch pad both return SHIP:LIQUIDFUEL but once launched the return values switch to the proper values. So the old rocket setup was bugged but this new rocket setup is working...once launched.



SET maxT to MAXTHRUST. //remember max thrust for staging.

//program foo.

IF MAXTHRUST < maxT {
LOCK throttle to 0. //Prepare to stage.
WAIT 3.
STAGE.
SET maxT to MAXTHRUST. //Re-initalize maxT.
WAIT 2. //Wait for stage seperation.
LOCK throttle to 1.
}

Doesn't that cause it to stage if you shut off your engine? Ex. coasting to ap. I just took a more manual approach and grabbed the amount from the part itself and controlled staging this way. I like to work in "chunks" or modes so turning off thrust to stage won't work for me. This is what I got so far...still testing it tho.


// Requires you to kOS tag fuel tanks with "fuel tank". Test script for staging multiple types of engines/boosters and fuels
CLEARSCREEN.
SET mode to 1.
SET amt to 0.

until mode = 0 {
if mode = 1 {
SET ftank to SHIP:PARTSTAGGED("fuel tank")[1].
SAS ON. STAGE.
SET mode to 2.
}
else if mode = 2 {
when amt < 1 then {
SET mode to 3.
STAGE.
}
}
else if mode = 3 {
SET ftank to SHIP:PARTSTAGGED("fuel tank")[0].
when amt < 1 then {
SET mode to 4.
STAGE.
}
}
SET amt to ftank:resources[0]:amount.
PRINT "MODE : " + mode + " " at (1,11).
PRINT "Fuel remaining: " + round(amt) + " " at (1,12).
}

Edited by Smokie23
Link to comment
Share on other sites

Doesn't that cause it to stage if you shut off your engine? Ex. coasting to ap. I just took a more manual approach and grabbed the amount from the part itself and controlled staging this way. I like to work in "chunks" or modes so turning off thrust to stage won't work for me. This is what I got so far...still testing it tho.

No, it does not. MAXTHRUST is independent of the throttle setting. It is simply the maximum thrust a ship is capable of producing at any given moment. Thus you can cut engines, throttle back, or what have you without it staging.

Link to comment
Share on other sites

No, it does not. MAXTHRUST is independent of the throttle setting. It is simply the maximum thrust a ship is capable of producing at any given moment. Thus you can cut engines, throttle back, or what have you without it staging.

Yes. And to further describe it:

SHIP:MAXTHRUST: Thrust you could have given the current list of active engines if you assume they are all fueled, and none of them are thrust limited, and you put the throttle at max.

SHIP:AVAILABLETHRUST: Like MAXTHRUST, except it does take into account how you have the thrust limiters currently set. It's the amount of thrust you'd get at max throttle but leaving the thrust limiters engaged as they are.

Current actual Thrust should be SHIP:AVAILABLETHRUST * THROTTLE.

Link to comment
Share on other sites

Are you saying that the command:

STAGE.

does not work?

Or perhaps is he referring to the fact that sometimes the last few bits of fuel are not used up for some reason so the tank technically isn't empty and if that's what the code is waiting for, then it won't stage.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...