[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Izandral]

how do i do rotations ? or more specifically prevent them. I want to burn surface retrograde , i'm using lock steering to R(0,0,0)*V(0-vs:x,0-vs:y,0-vs:z). But this causes the ship to rotate to have the north up on the nav ball.

I want to ship to got to retrograde while keeping it's current rotation.

[kaesekuchen]

how do i do rotations ? or more specifically prevent them. I want to burn surface retrograde , i'm using lock steering to R(0,0,0)*V(0-vs:x,0-vs:y,0-vs:z). But this causes the ship to rotate to have the north up on the nav ball.

I want to ship to got to retrograde while keeping it's current rotation.

I'm afraid that this is a bit trickier.

With the current state of kOS i haven't got this working unless you go the distance and do your own vector calculations from the getgo and use that system instead of the "premade" vectors kOS supplies for landmark (retrograde, prograde etc.) navigation.

Steven Mading spent some time on this and wrote quite a few posts on this and i'll be so blunt to refer you to them for further reading.

The main issue at this moment is, that we can't retrieve the current vessel's roll.Marianoapp stated, that once the big merge has been done, we will have a way to retrieve it.

[CaptainKipard]

I'm pretty sure you can use this:

lock steering to up+(whatever)

up is always away from the planet/moon center, so it'll rotate constantly to compensate.

I'm not sure why you'd want that though. That's not how you execute burns.

If you want to align yourself to a constant vector at a specific point on your orbit, then you can tell your script to create a node at a specific point, and then do this:

lock steering to nextnode.

Edited March 10, 2014 by Cpt. Kipard

[kaesekuchen]

The issue at hand is, that (usually) the roll of your ship does not affect your burn. So it wouldn't matter if we are "upside down" or 90 degree rolled to the right, as long as we point to our destination.

What izandral is looking for (unless of course i'm mistaken) is a way to change your orientation while maintaining your current roll orientation and therefore avoiding any unnecessary change on your ship's roll axis.

[Izandral]

The issue at hand is, that (usually) the roll of your ship does not affect your burn. So it wouldn't matter if we are "upside down" or 90 degree rolled to the right, as long as we point to our destination.

What izandral is looking for (unless of course i'm mistaken) is a way to change your orientation while maintaining your current roll orientation and therefore avoiding any unnecessary change on your ship's roll axis.

yep pretty much that , when i try to go to retrograde because of the roll the ship does not go to the new nav point (retrograde) by the shortest route. It rolls around way off mark before setteling. On a small ship it's not much of a problem because it's manoeuvrable but on something less agile it adds way to much delay

Edited March 10, 2014 by Izandral

[CaptainKipard]

OK that's beyond my knowledge then, except maybe you could write a script to change your orientation in e.g. 30 degree increments, you can use the dot product to check vector directions if I'm right, and then do another orientation change until you're done.

[Kethevin]

I'm sorry if this is a silly question, but I'm not sure what I'm doing wrong. If K-OS loses signal it stops working, which is fine and I like that. But when it finally regains signal, it still doesn't work. Instead of an error it just doesn't do anything. If I type something it doesn't recognize, it says so, but if it's a valid command it doesn't do anything.

In addition, if I turn the power off, I don't seem able to power it back up. :-(

Please help.

EDIT: I'm able to power it up and down just fine if I have a current signal. If I deactivate the antenna I can still power it up and down; however, once I enter a command that generates the error "Signal interruption: Transmission Lost," it becomes totally dysfunctional, regardless of the condition of the antenna.

EDIT2: Leaving focus on the ship and returning restores function. Sorry. *blush*

Edited March 11, 2014 by Kethevin

[Kethevin]

I'm curious if someone could give me an example of a simple program to circularize your orbit. It is likely poorly done, but I've been using:

set x to apoapsis - 500.

set y to x - 2000.

lock steering to prograde.

wait until eta:apoapsis < 20.

lock throttle to 1.

wait until periapsis >= y.

lock throttle to .5.

wait until periapsis >=x.

lock throttle to 0.

I had it throttle back to 50% because I thought it might help keep the apoapsis from changing. The problem I'm having is instead of making the orbit circular it stretches out instead. I start with an apopasis of around 80,000. After this program runs, the perapsis does stop near 80,000 but by the time that happens, my apoapsis shoots out to over 1,000,000.

I apologize for the crudeness of the program, I'm a beginner. :-)

EDIT: To explain why I used X and Y, I was afraid the original problem was the changing apoapsis, so I decided to lock it into a set figure by placing it in a variable. My goal is to have a simple program for my future satellites that allow me to run and have it circularize at whatever apoapsis I have it start with.

[kaesekuchen]

The problem with circularizing your orbit is, that in an ideal circular orbit periapsis and apoapsis would be interchangeable.

So if your intention is to write a program, that is very flexible and efficient you have to take a look at quite a few cases.

1) your periapsis needs to be higher

a) will the new periapsis be higher than the current apoapsis ?

- burn at current apoapsis, until apoapsis is higher than desired altitude for periapsis

will the new periapsis be smaller than the current apoapsis?

- burn at current apoapsis, until periapsis is higher than desired altitude for periapsis

2) your apoapsis needs to be higher

- burn at current periapsis, until apoapsis is higher than desired alt. for apoapsis

3) your periapsis needs to be smaller

- burn at current apoapsis, until periapsis is smaller than desired alt. for periapsis

4) your apoapsis needs to be smaller

a) will the new apoapsis be higher than the current periapsis?

- burn at periapsis, until apoapsis is smaller than desired alt. for apoapsis

will the new apoapsis be smaller than the current periapsis?

- burn at periapsis, until periapsis is smaller than desired alt. for apoapsis

These are the 4 cases you have to take into consideration.

It's usually easier to implement it with a certain threshold, saying you want to circularize at 100km, you should first execute the burns, until your periapsis is between 99.5km and 100km and your apoapsis is between 100km and 100.5km.

I hope this pseudocode helps, otherwise i can cleanup the circularizing script i wrote and post that.

[Dunbaratu]

I'm curious if someone could give me an example of a simple program to circularize your orbit.

In general I've found it massively useful to always remember this in the top of my head in any thinking about maneuvers in KSP:

"Always, always, always, your predicted orbital ellipse must necessarily include returning to your current position."

In other words, your current location is the "pivot point" of any maneuver burn - the one position, locked in place, that must always be part of the new orbital path you're creating.

Keeping that at the top of your mind helps avoid a lot of pitfalls. In this case it helps remind you that it's impossible to raise your periapsis higher than your current altitude because (periapsis <= altitude <= apoapsis) must always be true if your current location has to be on the orbital ellipse.

What's happening in your case is that before you hit the point where periapsis >= (original apopasis - 2500), periapsis has rotated position with apopapsis so that now apoapsis is on the far side and periapsis is near you. At that point your orbit has already passed through circular and you're now stretching it out again by burning more. And this has happened before periapsis got to within 2500 of what apoapsis used to be so your script didn't catch it and stop you.

Try this logic instead:

"Burn until diff between my current periapsis and my current altitude is a smaller number than the diff between my current altitude and my current apoapsis."

You can do that in one simple "wait until" expression.

That will burn until you pass the point where you've pushed the apoapsis around to the other side of the orbit from you. I used this and it works like a charm every time.

Your logic to slow down the burn as you get close to the cutoff point is good tactic to get more precision, but the way I typically do that is to lock the throttle to a math expression that continuously gets closer to zero as it gets closer to the endpoint, like this for example:

lock throttle to 0.01 + (apoapsis - periapsis)/5000 .

In that example, the throttle stays > 1.0 (which kOS just takes to mean the same as 1.0) as long as apoapsis is more than 5000m higher than periapsis, but then it starts scaling down from 1.0 down to 0.01 as the difference between apoapsis and periapsis scales from 5000m to 0m.

The reason for adding 0.01 is that you need to avoid the case where you asymptotically approach the endpoint without ever actually quite reaching it, which is what could happen if you bring the throttle to exactly zero as you bring the oribit to exactly circular.

[marianoapp]

I approached circularization from a math point of view, so I first calculate the velocity needed to achieve a circular orbit and then the difference between that and the velocity I will have at apoapsis is the node deltav.

Snippet of my circularization program

// orbitAltitude = desired altitude of the circularized orbit
// g_bodyRadius = 600km (kerbin)
// g_bodyGM = 3531600000000 (kerbin)

set absoluteOrbitAltitude to g_bodyRadius + orbitAltitude.
print "Target orbit: " + orbitAltitude + "m".

// calculate required orbital velocity to achieve a circular orbit
set requiredOrbitalVelocity to sqrt(g_bodyGM / absoluteOrbitAltitude).
print "Required orbital velocity: " + round(requiredOrbitalVelocity, 3) + "m/s".

// calculate orbital velocity at apoapsis
set SMa to (alt:apoapsis + alt:periapsis + 2*g_bodyRadius) / 2.
set apoapsisOrbitalVelocity to sqrt(g_bodyGM*((2/absoluteOrbitAltitude)-(1/SMa))).
print "Apoapsis orbital velocity: " + round(apoapsisOrbitalVelocity, 3) + "m/s".

// add the node
set nodeDeltaV to requiredOrbitalVelocity - apoapsisOrbitalVelocity.
set maneuverNode to node(time:seconds + eta:apoapsis, 0, 0, nodeDeltaV).
add maneuverNode.

// execute the node (execnode is a program I wrote for that)
run execnode(Isp).

[Kethevin]

Thanks everyone, I'm learning! :-)

@Marianoapp Could you show me your execnode program?

So far I've had limited success, the closest I come is having the periapsis about 10KM below the apoapsis. I realize getting it exact is unlikely, but I'd like to shoot for a closer margin.

I think my current issues lie in when to start the burn. Too soon and the apoapsis climbs with the burn, too late and I pass over the apoapsis during the burn. I'm thinking it's not going to be a one size fits all as I understand it, the mass of the craft and the thrust of the engine will change the most appropriate burn spot? Is that correct?

[marianoapp]

I think my current issues lie in when to start the burn. Too soon and the apoapsis climbs with the burn, too late and I pass over the apoapsis during the burn. I'm thinking it's not going to be a one size fits all as I understand it, the mass of the craft and the thrust of the engine will change the most appropriate burn spot? Is that correct?

The exact moment to start the burn is when your are at the apoapsis of the suborbital trajectory (the top of the parabole after launch), but since the circularization burn takes time you have to start a little early so you burn evenly before and after the apoapsis. And yes, the ship mass and thrust affect the burn time and therefore how early you have to start the burn.

@Marianoapp Could you show me your execnode program?

My execnode script is this, it calculates the burn time taking into account the ship mass, thrust and engine efficiency (isp parameter).

declare parameter Isp.

set Ispg to Isp*9.82.
set maneuverNode to nextnode.

// lock the steering to the node
sas off.
lock nodeDirection to (R(0,0,0)*maneuverNode:burnvector) + R(0,0,180).
lock steering to nodeDirection.

// calculate burn time
set finalMass to ship:mass / ((constant():e) ^(maneuverNode:burnvector:mag / Ispg)).
// adjust thrust so the burn time is at least 1s.
set burnThrottle to 1.
set burnTime to 0.
until burnTime >= 1
{
    set massFlowRate to (ship:maxthrust*burnThrottle) / Ispg.
    set burnTime to (ship:mass - finalMass) / massFlowRate.    
    if burnTime < 1 { set burnThrottle to 0.75*burnThrottle. }.
}.
print "Burn time: " + round(burnTime, 3) + "s @ " + round(burnThrottle * 100) + "%".

// throttle up delay
set startDelay to 0.97.
wait until maneuverNode:eta <= ((burnTime / 2) + startDelay).
// start burn
lock throttle to burnThrottle.
wait burnTime - 0.02.
lock throttle to 0.

unlock steering.
sas on.

remove maneuverNode.

[Kethevin]

I can almost follow some of that! Would you mind if I copied it and tried it out in my game? I tend to learn faster through a more hands-on approach if that makes sense.

[Kethevin]

Could you tell me what I'm doing wrong here? I made a short script to deorbit junk. I wrote this:

clearscreen.

print "Executing de-orbit burn.".

wait 1.

lock steering to retrograde.

wait 2.

lock throttle to 1.

Instead of locking to retrograde, the ship spins. If I type it manually it works. Also, the throttle never goes up, but also works if I type it manually. I put the waits in thinking it needed something between the commands.

Thanks.

EDIT: Also... after typing it manually, it doesn't hold after putting the throttle to 1; I have to type "lock steering to retrograde." a second time.

Edited March 12, 2014 by Kethevin

[Dappa]

Could you tell me what I'm doing wrong here? I made a short script to deorbit junk. I wrote this:

clearscreen.

print "Executing de-orbit burn.".

wait 1.

lock steering to retrograde.

wait 2.

lock throttle to 1.

Instead of locking to retrograde, the ship spins. If I type it manually it works. Also, the throttle never goes up, but also works if I type it manually. I put the waits in thinking it needed something between the commands.

Thanks.

EDIT: Also... after typing it manually, it doesn't hold after putting the throttle to 1; I have to type "lock steering to retrograde." a second time.

The problem with your script is that it just ends immediately after locking the throttle. That resets the throttle, and keeps the ship spinning if it wasn't done turning to retrograde.

To prevent your script ending too soon, try adding the following at the end:

wait until periapsis < 0.

That should keep your script running until you're de-orbited.

[Kethevin]

Thanks! I appreciate the help.

[Izandral]

i have a problem with orientation. When i print ship:direction i get numbers , but if i try to assign pitch , yaw or roll to a variable they always end up 0. Is there a way to know my current orientation and use it after ?

Another problem/question/idea i have, is there a way to do something along the line of --- PITCH: POSITIVE:1--- which would pitch the ship up for 1 sec, like actually holding the S key for 1 sec.

Because right now if i use locksteering the controls move all around the place , turns very slowly in the right direction and waste a ton of Mono. It's fine for small adjustment but for large orientation changes it's not practical. It seems the ship is moving in small(really small) rotation increment and stabilising each time until it's at the proper heading.

Edited March 13, 2014 by Izandral

[frencrs]

i have a problem with orientation. When i print ship:direction i get numbers , but if i try to assign pitch , yaw or roll to a variable they always end up 0. Is there a way to know my current orientation and use it after ?

Another problem/question/idea i have, is there a way to do something along the line of --- PITCH: POSITIVE:1--- which would pitch the ship up for 1 sec, like actually holding the S key for 1 sec.

Because right now if i use locksteering the controls move all around the place , turns very slowly in the right direction and waste a ton of Mono. It's fine for small adjustment but for large orientation changes it's not practical. It seems the ship is moving in small(really small) rotation increment and stabilising each time until it's at the proper heading.

You can use "LOCK" instead of "SET" to set a variable to return your current orientation.

And for the manual pitch/yaw/roll controls, the latest release info explains their addition: https://github.com/erendrake/KOS/releases

For example: "SET SHIP:CONTROL:YAW to 0.2" would cause the ship to start rotating at 20% of it's control thrust/torque, "SET SHIP:CONTROL:YAW to -0.2" would cause the ship to start rotating at 20% in the opposite direction. The same applies for PITCH and ROLL.

FORE and STARBOARD can be a little confusing, basically if you want the ship to translate aft at 100% you would do "SET SHIP:CONTROL:FORE to -1" and if you want the ship to translate port at 100% you would do "SET:SHIP:CONTOL:STARBOARD to -1"

[marianoapp]

i have a problem with orientation. When i print ship:direction i get numbers , but if i try to assign pitch , yaw or roll to a variable they always end up 0. Is there a way to know my current orientation and use it after ?

[TARGET]: DIRECTION is the direction from your ship to the target ship, but in this case the target ("SHIP") is your own ship, so the direction is zero "R(0,0,0)". What you need to use is SHIP:FACING that returns a rotation that represents the direction in which your ship is pointing.

[aNewHope]

Hi, Erendrake,

I have a request for the upcoming update(s): Right now kOS seems to be incapable of putting out a number to a power, that is not an Integer.

I would really need that functionality in order for this program to work (It gives out a list for an almost perfect gravity turn).

declare parameter twr,v0,psi0.

print "Computing Trajectory" at (Ic,stl).
print "Progress:" at (Ic,Il+6).
print "0 %" at (Ic2,Il+6).

set z0 to -tan(0.5*psi0).
set c to v0/(z0^(twr-1)+z0^(twr+1)).
set gt to list().

set n to 0.
set zm to 0.5.

lock v to 5*n^2+55*n+10.
lock vm to c*zm^(twr-1)*(1+zm^2).

until n > 12{
	set zmin to 0.
	set zm to 0.5.
	set zmax to 1.
	until round(vm,0)=v{
		if vm>v {set zmax to zm.}
		if vm<v {set zmin to zm.}
		set zm to (zmin+zmax)/2.
	}
	set n to n+1.
	set gt:add to 90+2*arctan(zm).
	print round(100*n/12) + " %" at (Ic2,Il+6).
}

print "                    " at (Ic,stl).
print "         " at (Ic,Il+6).
print "         " at (Ic2,Il+6).

Edit: Problem is solved.

Edited March 14, 2014 by aNewHope

[a5xq]

You can add IF .. ELSE statement?

Without it, my script for automatic control capacitors (Near Future Propulsion) very ugly.

[frencrs]

Hi, Erendrake,

I have a request for the upcoming update(s): Right now kOS seems to be incapable of putting out a number to a power, that is not an Integer.

I would really need that functionality in order for this program to work (It gives out a list for an almost perfect gravity turn).

I believe kOS returns floating points if the result is a floating point.

Are you talking about results like this? (Ignore the up-arrow symbol, it is being shown in place of the ^ symbol for some reason.)

[Dunbaratu]

Hi, Erendrake,

I have a request for the upcoming update(s): Right now kOS seems to be incapable of putting out a number to a power, that is not an Integer.

In the days before the SQRT operator you had to get a square root by taking something to the power ^0.5 and that worked just fine. Are you sure this doesn't work?

[marianoapp]

Hi, Erendrake,

I have a request for the upcoming update(s): Right now kOS seems to be incapable of putting out a number to a power, that is not an Integer.

Are you using v11.1 or the 12.0 prerelease? We made a major rewrite of several parts of the mod and in the new version you can raise a number to any power you want.

Edited March 14, 2014 by marianoapp