[1.3] kOS Scriptable Autopilot System v1.1.3.0

[AfailingHORSE]

thanks

[Parallax]

The idea is that its a plane, but instead of landing gear with wheels, it will have cyborg legs and do running takeoffs and landings.

Im using my own servo sequencer template script to generate the walking part of the script ( [based on an earlier craft i made](http://forum.kerbalspaceprogram.com/threads/126654-Long-Jumping-Bipedal-Robot-%28craft-script-included%29-INFERNAL-ROBOTICS-kOS) ), so that part is done.

however, i made my template script a while ago and since then forgot how to kOS. here what im stuck on: my walking script relies on controlling from the upward facing control probe and locking heading in the upward direction with SAS; but to fly the plane properly i need to control from the probe core that faces forward and have any SAS commands disabled.

right now it can do a running takeoff and flies well enough once i manually switch to the foreward facing probe core, but its impossible to land without the ability to make the switch at exactly the right time...

basically i want to be able to toggle between which of the two probe i "control from", and apply the appropriate SAS setting for the selected probe.

any ideas?

[Alchemist]

PART:CONTROLFROM

[baldamundo]

Hey. Used to use this a bunch way back in 0.90, but am coming back to KSP after a long hiatus and can't remember anything. Don't really feel like jumping in right at the deep end with kOS and scripting from scratch so...anyone fancy sharing their scripts for me to reverse engineer?

Even just launch-to-LKO and node-execution scripts would be really appreciated to get me started!

[Qigon]

Hey. Used to use this a bunch way back in 0.90, but am coming back to KSP after a long hiatus and can't remember anything. Don't really feel like jumping in right at the deep end with kOS and scripting from scratch so...anyone fancy sharing their scripts for me to reverse engineer?

Even just launch-to-LKO and node-execution scripts would be really appreciated to get me started!

There are a couple of examples here http://ksp-kos.github.io/KOS_DOC/library.html

[baldamundo]

There are a couple of examples here http://ksp-kos.github.io/KOS_DOC/library.html

These all seem very abstract though, unfortunately. I'd be much better off with something that straightforwardly performs a useful in-game function directly which I can then start using, examining, understanding, retuning, reverse-engineering etc. Trying to put something useful together more from scratch or from these libraries I fear is beyond me right now

[Parallax]

something strange is happening.

im trying to use an action group to toggle between controlling from the forward facing probe core with SAS off and controlling from the upward facing probe with steering locked upward.

i got it to toggle between controlling from the two different probes by doing this:

SET UPPROBE TO SHIP:PARTSTAGGED("UPPROBE")[0].
SET FWDPROBE TO SHIP:PARTSTAGGED("FWDPROBE")[0].

UNTIL ALTITUDE=20000

{

IF AG1=1

FWDPROBE:CONTROLFROM.

ELSE 

UPPROBE:CONTROLFROM.


}.

but when i add the code to set the SAS commands, like so:

SET UPPROBE TO SHIP:PARTSTAGGED("UPPROBE")[0].
SET FWDPROBE TO SHIP:PARTSTAGGED("FWDPROBE")[0].

UNTIL ALTITUDE=20000

{

IF AG1=1

FWDPROBE:CONTROLFROM.
UNLOCK STEERING.

ELSE 

UPPROBE:CONTROLFROM.
LOCK STEERING TO Up + R(0,0,90).

}.

i get an error. what gives?

Edited October 17, 2015 by Parallax

[Dunbaratu]

i get an error. what gives?

1: Your example code doesn't use any curly braces around the body of the if and else conditions.

This:

if whatever {
  statement1.
  statement2.
}
else {
  statement3.
  statement4.
}

Works fine, but when you leave the braces off, it only takes the next single statement as the if body, so it effectively ends up doing this (indentation to show what is and is not the body of the IF:

if whatever
  statement1.
statement2. // The 'if' body was over after statement1.  This statement happens unconditionally.
else // This should give a syntax error because it's not connected to a preceding "IF".
  statement3.
statement4.

2: You mention SAS in your description, but nothing in the code you showed mentioned SAS.

- - - Updated - - -

These all seem very abstract though, unfortunately. I'd be much better off with something that straightforwardly performs a useful in-game function directly which I can then start using, examining, understanding, retuning, reverse-engineering etc. Trying to put something useful together more from scratch or from these libraries I fear is beyond me right now

You want this: http://ksp-kos.github.io/KOS_DOC/tutorials.html

Beware that the execute node script mentioned there is designed to be easy to understand rather than actually perfectly correct. It does not deal with calculating the fact that your acceleration changes over time as your fuel burns off, and instead it pretends you have constant acceleration when deciding how to time the burn. (It assumes constant acceleration (which is false) and uses that to calculate how long the burn will take, then starts the burn exactly half that much time ahead of the node's time). A 100% correct maneuver node calculation would use the Tsiolkovsky rocket equation to find out how much time it will take to give the first 1/2 of the delta-V, and start THAT many seconds ahead of time.

Edited October 17, 2015 by Steven Mading

[Drew Kerman]

Beware that the execute node script mentioned there is designed to be easy to understand rather than actually perfectly correct. It does not deal with calculating the fact that your acceleration changes over time as your fuel burns off, and instead it pretends you have constant acceleration when deciding how to time the burn. (It assumes constant acceleration (which is false) and uses that to calculate how long the burn will take, then starts the burn exactly half that much time ahead of the node's time). A 100% correct maneuver node calculation would use the Tsiolkovsky rocket equation to find out how much time it will take to give the first 1/2 of the delta-V, and start THAT many seconds ahead of time.

baldamundo You can use this derivation I found on the forums a while back. I use it for calculating all my burns since I have a HOTAS joystick that doesn't trigger KSP's built-in burn timer. I also use it in my RCS Thrust Controller script if you want a practical example.

[Alchemist]

Is there an option to see the pitch/yaw/roll of the cooked control (or the actual control applied to the craft after all the sources) from inside the script? For example, to use asymmetrical throttling for more control authority. Or is this the "write your own PID controller" case?

[Qigon]

These all seem very abstract though, unfortunately. I'd be much better off with something that straightforwardly performs a useful in-game function directly which I can then start using, examining, understanding, retuning, reverse-engineering etc. Trying to put something useful together more from scratch or from these libraries I fear is beyond me right now

I guess that by function you mean as in in-game behaviour, not as in programming language's methods?

There are these tutorials: http://ksp-kos.github.io/KOS_DOC/tutorials/quickstart.html

There's also this twitch from dunbaratu http://www.twitch.tv/dunbaratu/v/8888071 where he writes an airplane autopilot from scratch, it's very cool AND useful. Do twitches expire? that would be sad. I can't get into this link right now, I'm not sure whether it's the twitch or my connection that went rogue.

edit:

oh, I see Steve beat me to it. By like, 2 days .

Edited October 19, 2015 by Qigon

[Drew Kerman]

Anyone have advice on calculating distance traveled? Mainly from launch to orbit. Persistent Trails does this but not with the granularity I want, and the ability to log it every second. Dealing with acceleration during ascent is the part I'm having trouble with mostly

[gruneisen]

I'm having an issue where when I invoke LOCK STEERING TO HEADING(X,Y), all of the controls oscillate rapidly and the rocket will not respond or change course - I'm using a rocket that has no SAS, RCS, or engine gimbal - only ailerons. Is this the reason why LOCK STEERING will not control the rocket?

Thanks!

- - - Updated - - -

I'm not familiar with github, so I'll post it here hoping you guys read it.

In relation to my previously submitted issue (#389, LOCK STEERING broken for RCS-only (no torque) ships), and the related fix attempt (#1118, github user hvacengi is committing there). At the latest KSP/kOS version my RCS-only craft responded to LOCK command properly and aligned itself onto a given heading. But my gimbal-only (no reaction wheels, no RCS) craft ended up exactly the same as the other one.

Reproduction steps include building a craft that only has a non-torque probe core, kOS computer, fuel tank and gimbal-equipped engine and launching it under gravity hack. Inputting a LOCK STEERING command into the terminal makes the gimbal wobble like in the video for the previous issue, which I linked above.

Not sure if hvacengi's solution is going to be a major rework of the cooked control system that would solve that case too, in any case I'm letting you know about the issue.

I recently started a RSS/RO save and attempted to write kind of a real-life autopilot using Powered Explicit Guidance algorithm, but I never had the patience to do PID tuning, so I'd rather be able to use cooked control than try to align the craft on the pilot input mode

I went back into Reddy's linked issues and his YouTube video seems to show the same problem I'm having, so I guess this makes two of us. I too am using RSS / RO, which is why I have no RCS and no SAS on my rocket.

Thanks again for any help.

Edit again: further looking into Reddy's post and the linked issues on github show that my issue is the same as all the rest. I retract my questions and will await the updated release.

Thanks!

Edited October 21, 2015 by gruneisen

[gruneisen]

Ok - so you guys are probably tired of me bleating about on this forum, but I'm new to kOS and am trying to use it to perform an ascent profile for a Mercury Redstone launch. Seeing as the Mercury Redstone only used four small aelerons for attitude control in the atmosphere, I cannot use the kOS cooked steering controls for this launch.

I know that the capability is being added in (and has already been done so), but while I wait for the next dev or release build, I'm attempting to create my own autopilot script for this launch.

I'm having a hard time figuring out where to begin - I've been through the tutorials and understand them, but I'm still having trouble figuring out how to control the orientation of the rocket.

I'm determining my current orientation by using setting three variables to ship:facing:yaw, :pitch, and :roll. I then treat those values as my control value with the assumption that my rocket is going to ascend vertically. In my loop, I re-read the ship:facing:pitch, :yaw, and :roll, compare them to my control values, and assign the resultant error to ship:control:pitch, etc. I'm just using a simple proportional gain right now.

Is this nominally correct or even a good way of doing this? Is there some other way of determining the rockets orientation and controlling it which may be more appropriate?

Thanks in advance and if there's an answer already out there to this question, please kindly point me towards it!

[Dunbaratu]

Trying to control all three axes at the same time can get really wonky. You usually get better performance if you limit it to just two of them at first, and only allow it to work on the third after the first two are kinda close to right.

[gruneisen]

Thanks Steven -

Can you comment on whether it is better to control based on the absolute pitch, yaw, and roll relative the celestial body, as I am doing, or to use the 'navball' quantities which can be provided by the lib_navball.ks library?

Thanks!

[AfailingHORSE]

I'm trying to stage 4 of my 6 SRBs, im trying to use the tag system and the documentation site for it isnt exactly helpful on this subject.

SET solidStage TO SHIP:PARTSDUBBED("SSAB"). //Outside 4 SRBs
SET solidStage TO SHIP:PARTSDUBBED("SSC"). //Inside 2 SRBs

........

FOR solidStage IN SHIP:PARTSDUBBED("SSAB") {
	WAIT UNTIL SHIP:SOLIDFUEL < 45.
		PRINT "STAGE TEN SEPERATION IN:".
		FROM {local countdown is 3.} UNTIL countdown = 0 STEP {SET countdown to countdown -1.} DO {
			PRINT "..." + countdown.
			WAIT 1.
			IF countdown = 2 {
				AG5 ON.
			}
			IF countdown = 1 {
				STAGE.
				PRINT "Stage ten separated.".
			}
		}
}

FOR solidStage IN SHIP:PARTSDUBBED("SSC") {
	WAIT UNTIL STAGE:SOLIDFUEL < 45.
		PRINT "STAGE NINE SEPERATION IN:".
		FROM {local countdown is 3.} UNTIL countdown = 0 STEP {SET countdown to countdown -1.} DO {
			PRINT "..." + countdown.
			WAIT 1.
			IF countdown = 2 {
				AG5 ON.
			}
			IF countdown = 1 {
				STAGE.
				PRINT "Stage nine separated.".
			}
		}
}

[Dunbaratu]

Thanks Steven -

Can you comment on whether it is better to control based on the absolute pitch, yaw, and roll relative the celestial body, as I am doing, or to use the 'navball' quantities which can be provided by the lib_navball.ks library?

Thanks!

Definitely lib_navball, because otherwise your control value is probably in a different rotation scheme than the native raw one. "pitch", "yaw", and "roll" don't really mean pitch, yaw, and roll. I HATE those terms but they pre-date me and were in the mod from the beginning, making it rather breaking of backward compatibility to rename them now. They actually mean just Euler rotation angles around the x,y, and z axes respectively, and those axes in the native coord system have nothing to do with how your ship is pointed or how the planet is oriented, therefore the names are misleading.

If you haven't done so already, take the time to watch this, as it gets into the XYZ axes of native KSP and how they look. Not understanding this will really mess up any script you write:

- - - Updated - - -

I'm trying to stage 4 of my 6 SRBs, im trying to use the tag system and the documentation site for it isnt exactly helpful on this subject.

Your first one says to wait until SHIP's solidfuel is < 45, and the second one says to wait until the single STAGE's solidfuel is < 45.

By the time the entire ship's solidfuel is < 45, it's impossible for any single stage to have more than 45 in it, so you'll get both these things firing back to back. By the time the first condition is true, the second one has to already be true too.

[AfailingHORSE]

- - - Updated - - -

Your first one says to wait until SHIP's solidfuel is < 45, and the second one says to wait until the single STAGE's solidfuel is < 45.

By the time the entire ship's solidfuel is < 45, it's impossible for any single stage to have more than 45 in it, so you'll get both these things firing back to back. By the time the first condition is true, the second one has to already be true too.

The ship's solid fuel was from a test that I forgot to change back to stage. But that is besides the point.

All six SRBs fire on the same stage, the outer 4 will run out of fuel first and I want them to drop first. However, for code modularity reasons, I want the stage when there is a specific amount of fuel left in those engines (in this case, 45 or less).

What is currently happening is that the outer 4 will hit 0 fuel, do nothing, and then when the inner 2 hit 44.999, the outer 4 stage and it loops the first FOR loop until it hits the 7th stage (see picture below).

The outer 4 engines are tagged SSAB and the inner 2 are tagged SSC.

SET solidStage TO SHIP:PARTSDUBBED("SSAB"). //Outside 4 SRBs
SET solidStage TO SHIP:PARTSDUBBED("SSC"). //Inside 2 SRBs

........

FOR solidStage IN SHIP:PARTSDUBBED("SSAB") {
	WAIT UNTIL STAGE:SOLIDFUEL < 45.
		PRINT "STAGE TEN SEPERATION IN:".
		FROM {local countdown is 3.} UNTIL countdown = 0 STEP {SET countdown to countdown -1.} DO {
			PRINT "..." + countdown.
			WAIT 1.
			IF countdown = 2 {
				AG5 ON.
			}
			IF countdown = 1 {
				STAGE.
				PRINT "Stage ten separated.".
			}
		}
}

FOR solidStage IN SHIP:PARTSDUBBED("SSC") {
	WAIT UNTIL STAGE:SOLIDFUEL < 45.
		PRINT "STAGE NINE SEPERATION IN:".
		FROM {local countdown is 3.} UNTIL countdown = 0 STEP {SET countdown to countdown -1.} DO {
			PRINT "..." + countdown.
			WAIT 1.
			IF countdown = 2 {
				AG5 ON.
			}
			IF countdown = 1 {
				STAGE.
				PRINT "Stage nine separated.".
			}
		}
}

[Lookerksy]

Four question:

1. How to use the keywords "batch" and "deploy"?

2. I can't understand what's math function ROUND(a, meaning.

3. If I SET SASMode TO StabilityAssist (or Stability) in kOS. What will happen?

4. The online manual(http://ksp-kos.github.io/KOS_DOC/) says:

If a vessel without antenna is more than 100km far from mission control center, the Volume 0 can't be visited from the vessel.

But when my vessel was near 500km orbit I still successed to do anything of Volume 0. What's matter?

[Dunbaratu]

The ship's solid fuel was from a test that I forgot to change back to stage. But that is besides the point.

All six SRBs fire on the same stage, the outer 4 will run out of fuel first and I want them to drop first. However, for code modularity reasons, I want the stage when there is a specific amount of fuel left in those engines (in this case, 45 or less).

What is currently happening is that the outer 4 will hit 0 fuel, do nothing, and then when the inner 2 hit 44.999, the outer 4 stage and it loops the first FOR loop until it hits the 7th stage (see picture below).

If all 6 engines are running, then the fuel for all 6 engines are summed together to form stage:solidfuel. The definition of the current stage values is the sum of all the resources available to all currently active engines.

You're better off just checking the status of the engines to see which ones have the :FLAMEOUT suffix being true, rather than counting fuel. That's more universal anyway.

- - - Updated - - -

Four question:

1. How to use the keywords "batch" and "deploy"?

No clue. They got added to the code base by someone else, and we've removed them because they literally did nothing.

2. I can't understand what's math function ROUND(a, meaning.

Return the value a, but rounded such that it has only b digits after the decimal point. Round(123.45678, 0) gives you 123. Round(123.45678, 2) gives you 123.46. Round(123.45678, 3) gives you 123.457.

3. If I SET SASMode TO StabilityAssist (or Stability) in kOS. What will happen?

Not really well defined when the autopilot is running things, as that's the mode that just dampens what the manual player does.

4. The online manual(http://ksp-kos.github.io/KOS_DOC/) says:

If a vessel without antenna is more than 100km far from mission control center, the Volume 0 can't be visited from the vessel.

But when my vessel was near 500km orbit I still successed to do anything of Volume 0. What's matter?

That's an obsolete description that's getting removed in the next release of the docs. It refers to what kOS used to do before it linked up with Remote Tech. Now if you don't install Remote Tech, you get no restrictions based on range at all. If you do install Remote Tech, then Remote Tech is in charge of deciding what counts as connected, and kOS just asks Remote Tech to tell it what the connectivity is.

[casper88]

Does anybody know if kos can read waypoints created in waypoint manger (http://forum.kerbalspaceprogram.com/threads/104758)?

i have a simple test script

set test to ALLWAYPOINTS().
set count to 0.
FOR wp in test {
    print wp:GEOPOSITION.
    set count to count + 1.
}
print count.

i run this after creating a waypoint; howvever the count at the end prints 0. Have I overlooked something or can't these waypoints be cycled?

Thanks

[Dunbaratu]

Does anybody know if kos can read waypoints created in waypoint manger (http://forum.kerbalspaceprogram.com/threads/104758)?

A the moment it's only finding waypoints by looking at the contracts system like it works in stock. I have no idea how the mod lists its non-contract waypoints. I could try to find out.

[Li_Cho]

use manual set...

set spot to latlng(0,-285). //

[Cakeofruit]

I've write a SSTO ascent script, tell me what you think about it

link : https://github.com/Cakeofruit/Kos.PlaneToOrbit

The real deal are in this file : https://github.com/Cakeofruit/Kos.PlaneToOrbit/blob/master/sp_guidance.ks