Jump to content

[1.3] kOS Scriptable Autopilot System v1.1.3.0


erendrake

Recommended Posts

9 hours ago, Natskyge said:

Does kOS work with realism overhaul?

It doesn't go out of its way to break RO, but RO does a thing that breaks kOS (sort of).  RO throws away all the stock meanings of how much 1 electric charge can do (1 EC), and when mapping it to a real-world measurement they picked one that is a bit nerfed compared to the stock game.  But then they compensate for this redefinition of what an EC is by editing all the configuration files of all the parts to use their new scaling meaning of 1 EC.  But kOS's EC usage isn't in a configurable .cfg file, so RO can't make that adjustment for it, and thus it makes the kOS power drain prohibitive when RO redefined what 1 EC meant.

There is a new feature in the pipeline that gives kOS CPU PartModules a configurable .cfg file setting for how many EC per instruction executed, which does two things:

1 - Power drain varies with CPU speed and CPU utilization percentage.  If your program is stuck on a wait statement for days while you time warp, you will use very minimal power during that wait.

2 - By having the value in a config file, RO can then overwrite it with whatever they want via modulemanager.

But right now that hasn't been released yet.

Link to comment
Share on other sites

Apologies if this is obvious and I missed it, but where’s the best place to get programming help?  I’ve written a halfway decent gravity turn script, and at the end I’m doing a thing that’s listed in the docs but getting syntax errors.  If this is the place to ask, I’ll happily post here, but if there’s a better channel I’ll happily go there instead.  Thanks!

Link to comment
Share on other sites

12 hours ago, meyerweb said:

Apologies if this is obvious and I missed it, but where’s the best place to get programming help?  I’ve written a halfway decent gravity turn script, and at the end I’m doing a thing that’s listed in the docs but getting syntax errors.  If this is the place to ask, I’ll happily post here, but if there’s a better channel I’ll happily go there instead.  Thanks!

this is the place.

Edited by leviathan01
Link to comment
Share on other sites

Thanks, leviathan01!  I’m running kOS 0.18.2 in KSP 1.0.5.1028.  The problem I have at the moment is I’m trying to turn on SAS and set the mode, like so:

SAS ON.
SET SASMODE TO "PROGRADE".

When I run the program, SAS turns on, but it doesn’t switch modes.  This is in a sandbox game and I’m in flight at the moment I try to switch on (doing about 9m/s at ~20m off the launch pad), so there is a prograde for me to try to switch to.  It’s part of a kOS script that launched the rocket and is reading out various flight parameters, so I know kOS is otherwise working.

I tried dropping the quote marks in case that was a misunderstanding on my part, and got instead:

Cannot cast from source type to destination type.
At ss on archive, line 21
SET SASMODE TO PROGRADE
               ^

So that doesn’t seem to be it.

Link to comment
Share on other sites

16 minutes ago, meyerweb said:

 


SAS ON.
SET SASMODE TO "PROGRADE".

 

It's most likely interfering with the (stock) feature that resets SAS mode when you reactivate it. So it seems that this happens after you set the mode (at the end of this / start of the next frame?) and resets it right back.

Try putting something like

WAIT 0.01.

inbetween the commands to skip a frame - that should work.

 

Link to comment
Share on other sites

1 hour ago, Alchemist said:

Try putting something like


WAIT 0.01.

inbetween the commands to skip a frame - that should work.

That was exactly it—thanks!  I’ll have to keep in mind the “if it doesn’t seem to work, WAIT a tick” approach.

On a related note, should the MANEUVER value in http://ksp-kos.github.io/KOS_DOC/commands/flight/systems.html#global:SAS be quoted?  It’s the only one that isn’t.

Link to comment
Share on other sites

13 minutes ago, meyerweb said:

That was exactly it—thanks!  I’ll have to keep in mind the “if it doesn’t seem to work, WAIT a tick” approach.

Yeah, some things don't fully conclude immediately on the command and take a frame or several to complete.

20 minutes ago, meyerweb said:

On a related note, should the MANEUVER value in http://ksp-kos.github.io/KOS_DOC/commands/flight/systems.html#global:SAS be quoted?  It’s the only one that isn’t.

Yes, it should - they all are strings.

Link to comment
Share on other sites

17 minutes ago, Alchemist said:

Yes, it should - they all are strings.

Good to know.  I’ve created a github issue and submitted a pull request, so hopefully it’ll be corrected soonish.

Now off to see if I can write kerboscript to intelligently (and efficiently) throttle-control the engines to keep the time-to-apoapsis at ~40s throughout the second phase of the turn…

Edited by meyerweb
Link to comment
Share on other sites

18 hours ago, leviathan01 said:

this is the place.

Well, technically this is just *a* place.  I wouldn't call it *the* place, because we tend to be more active over on reddit in /r/kos, and only pop in here once every few days to see if anyone commented.

Nothing against the forums, but the fact that with a programming system you can end up with very complex user questions, and lots of them for totally different topics, makes it feel really limiting that here everything about kOS has to be in one single thread.

I sometimes worry that that makes us look a lot less active than we really are, if people come here and see the traffic the thread has and don't realize there's way more going on over on reddit where people can talk in multiple threads.

Link to comment
Share on other sites

8 hours ago, Alchemist said:

It's most likely interfering with the (stock) feature that resets SAS mode when you reactivate it. So it seems that this happens after you set the mode (at the end of this / start of the next frame?) and resets it right back.

Try putting something like


WAIT 0.01.

inbetween the commands to skip a frame - that should work.

 

hmm.  that sounds like it needs to be a github issue.  Either we do some fiddling in the code to make it so SET SASMODE delays calling the KSP API until the next update when the SAS has changed, or we at least change the documentation so it mentions the wait.

Link to comment
Share on other sites

8 hours ago, Steven Mading said:

hmm.  that sounds like it needs to be a github issue.  Either we do some fiddling in the code to make it so SET SASMODE delays calling the KSP API until the next update when the SAS has changed, or we at least change the documentation so it mentions the wait.

It's not nearly the only case. For example, activating/deactivating an engine changes its thrust only next frame... and it looks like I found this issue in my own code for multi-mode engines when invoking events (while partModule:doEvent seems to avoid that - changing now to this method of event invoking)

 

Link to comment
Share on other sites

20 minutes ago, Alchemist said:

It's not nearly the only case. For example, activating/deactivating an engine changes its thrust only next frame... and it looks like I found this issue in my own code for multi-mode engines when invoking events (while partModule:doEvent seems to avoid that - changing now to this method of event invoking)

 

It's not the same thing at all.  Here's the important difference:
If you activate an engine there will be a delay until it happens next tick, but it will happen.

If you set sas on, then set sasmode to something, the set sasmode won't just be delayed until the next tick - it actually won't happen at all.

Link to comment
Share on other sites

10 minutes ago, Steven Mading said:

It's not the same thing at all.  Here's the important difference:
If you activate an engine there will be a delay until it happens next tick, but it will happen.

If you set sas on, then set sasmode to something, the set sasmode won't just be delayed until the next tick - it actually won't happen at all.

I just meant its the same in the sense that first command doesn't conclude immediately, therefore it may interfere with the second command (like activating the engine and immediately using the thrust in calculation can result in errors, too). But this SAS case is probably the easiest trap to fall into. At least we need to identify and document such cases.

Link to comment
Share on other sites

Maybe it will be a good idea to put reddit link somewhere in OP. There bunch of good info about change log, documentation, wikipedia, but there is no direct link for reddit for people that don't know about it.

Link to comment
Share on other sites

Just wanted to pop in here and say that I love this mod. I've spent entirely too much time this week coming up with scripts for a rocket and rover. I love the challenge and the feeling when it "just goes right."

 

However, I am a bit frustrated. Using a modified version of the tutorial code, I created a simple script that will launch my rocket into a 100km orbit and then circularize it. I spent around 10 hours on the code, learning and tweaking. Once finished, I took a break and worked on a rover-sky crane code, then went back and tried the rocket again. Exact same craft, exact same code - but instead of pitching 10 degrees after reaching the first threshold (100 m/s), the rocket flips and breaks apart. I'm curious as to why this never happened in the dozens of times I tested the code earlier, but now it happens consistently with every launch. 

I know it's not a problem with the code because I didn't touch it, but does KSP create slight variations in the parameters of every launch? I figured once coded, it would work perfectly every time. Has anyone else had a similar issue?

I'm nervous now that my sky crane code may randomly decide to not work, and I've probably spent another ten hours working on that one, too. 

Link to comment
Share on other sites

1 hour ago, -ctn- said:

I created a simple script that will launch my rocket into a 100km orbit and then circularize it

Even knowing it was based off the tutorial script there's so many things you could be doing to get this done we're going to need to see exactly what you're doing

Link to comment
Share on other sites

Well, the rocket flips because of aerodynamic forces - the first 10 degree pitch is too much and the whole thing ends up somersaulting. But I'm confused as to why it didn't do this during the dozens of times I was testing the code as I made it, and then ran the completed code three times in a row to make sure it was good.

Here's the entire code:

Spoiler

//Clearing the screen and getting ready for launch.
clearscreen.
set SASMODE to "STABILITYASSIST".
WAIT 0.5.
PRINT "SAS is go.".
RCS ON.
WAIT 0.5.
PRINT "RCS is go.".
LOCK THROTTLE TO 0.9.
WAIT 0.5.
PRINT "Launch is go.".

//Final countdown!
PRINT "Counting Down:".
FROM {local countdown is 10.} UNTIL countdown = 0 STEP 
{SET countdown to countdown - 1.} 
DO {
    PRINT "..." + countdown.
    WAIT 1.
	}
until SHIP:MAXTHRUST > 0 {
	WAIT 0.5.
	PRINT "Engines start.".
	STAGE.
	}
//Release clamps after ignition.
WAIT 1.0.
PRINT "Liftoff!".
STAGE.

//Actual ascent coding.
	UNTIL SHIP:APOAPSIS > 100000 {
	
	// If during ascent, an engine runs out of fuel, then stage.
	IF MAXTHRUST < 0.1 {
		WAIT 1.0.
		STAGE.
		PRINT "Stage Separation.".
		}
	
    //Head straight up at first.
    IF SHIP:VELOCITY:SURFACE:MAG < 100 {
        LOCK STEERING TO HEADING(90,90).

    //Once past 100m/s, pitch down ten degrees.
    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 100 AND SHIP:VELOCITY:SURFACE:MAG < 200 {
        LOCK STEERING TO HEADING(90,80).
        PRINT "Pitching to 80 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    //Gradually pitch down more and more.
    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 200 AND SHIP:VELOCITY:SURFACE:MAG < 310 {
        LOCK STEERING TO HEADING(90,70).
        PRINT "Pitching to 70 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 310 AND SHIP:VELOCITY:SURFACE:MAG < 400 {
        LOCK STEERING TO HEADING(90,60).
        PRINT "Pitching to 60 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 400 AND SHIP:VELOCITY:SURFACE:MAG < 500 {
        LOCK STEERING TO HEADING(90,50).
        PRINT "Pitching to 50 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 500 AND SHIP:VELOCITY:SURFACE:MAG < 600 {
        LOCK STEERING TO HEADING(90,40).
        PRINT "Pitching to 40 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 600 AND SHIP:VELOCITY:SURFACE:MAG < 700 {
        LOCK STEERING TO HEADING(90,30).
        PRINT "Pitching to 30 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 700 AND SHIP:VELOCITY:SURFACE:MAG < 800 {
        LOCK STEERING TO HEADING(90,20).
        PRINT "Pitching to 20 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    //The furthest we pitch is 10 degrees.
    } ELSE IF SHIP:VELOCITY:SURFACE:MAG >= 800 {
        LOCK STEERING TO HEADING(90,10).
        PRINT "Pitching to 10 degrees" AT(0,32).
        PRINT ROUND(SHIP:APOAPSIS,0) AT (0,33).

    }.

}.

PRINT "100km apoapsis reached, cutting throttle".
LOCK THROTTLE TO 0.
WAIT 2.0.
PRINT "Fairing Separation.".
STAGE.
WAIT 2.0.
PRINT "Ascent Program Ended.".
WAIT 0.5. 
PRINT "Clearing screen.".
WAIT 2.0.

//Begin circularization.
CLEARSCREEN.
PRINT "Begin Circularization Program.".
WAIT 2.0.
IF (PERIAPSIS < 95000) {
	print "Cruise until Apoapsis.".
	lock steering to PROGRADE.
	WHEN ALTITUDE > 71000 THEN {
		SET WARPMODE TO "RAILS".
		SET WARP TO 1.
		}
		
	until (ETA:APOAPSIS < 10) {
		print "Time to Apoapsis" AT(0,32).
		print (ETA:APOAPSIS) AT (0,33).
		WAIT 2.
		}
	SET WARP TO 0.
	WAIT 1.0.
	print "Circularization burn.".
	LOCK THROTTLE to 0.9.
	until (PERIAPSIS > 95000) {
		print ROUND (SHIP:PERIAPSIS) AT (0,34).
		WAIT 1.
		}
	LOCK THROTTLE to 0.
	}.

	//All done.
	PRINT "Orbit Acheived.".
	WAIT 1.0.
	PRINT "Circularization Program Ended.".
	WAIT 1.0.
	PRINT "Clearing Screen.".
	WAIT 1.0.
	
//New Screen.
	CLEARSCREEN.
	PRINT "Ready for Commands.".
	SET PILOTMAINTHROTTLE to 0.

 

 

Link to comment
Share on other sites

hrm. Nothing jumps out, for me at least. you sure when you reloaded coming back to the ship after working on the other code the rocket didn't jump on the pad or anything that would subtly change its liftoff position? I've seen jumpy rockets, but mainly from mods so if you're running mostly stock that shouldn't happen. Just a thought. You can't get exact same results when re-running the scripts so I guess there's a chance that your original runs were always just at the edge of not flipping out and it may not have taken a large change in the environment to cause a problem in later runs. Those are my best guesses anyways

Link to comment
Share on other sites

I found out the problem, and it's a little embarrassing. 

I have two copies of KSP installed, one slimmed down for development work on my own mods, and the other filled out with a bunch of mods I like. I developed the rocket launch code in the DEV copy and built the other code in the PLAY copy. Then I copied the code for the rocket launch from DEV to PLAY and that's when my rockets began to flip.

Turns out, PLAY is KSP version 1.0.5 and DEV is KSP version 1.0.2. I've edited the code to make the pitch maneuvers smaller (5 degree increments) and thus no flippage. Thanks for taking the time to look through the code, though. 

Link to comment
Share on other sites

Finally, my kOS suicide burn program is almost working perfectly! :)

 

 

 

Even a very low TWR (< 1.3) is no problem any more for the program, and it even works with really good with very high TWRs (>8). I now need to try to make the burn more like a burn, and not many short bursts. But I am very, very happy with it already, and so far, I haven't detected any issues. :)

Link to comment
Share on other sites

1 hour ago, -ctn- said:

That's awesome! Are you using if-else loops to turn on the throttle under a certain altitude and if it's over 2 m/s?

It's a bit more than that, but nothing complex.

First,  first the program calculates g of the body (9.81m/s or 9.81m/s*s). Then, based on the ships mass and availablethrust, it calculates the TWR. Then, once we know the maximum TWR of the ship, we can directly calculate its acceleration, since a TWR of 1 means, that the rocket hovers, meaning it has an acceleration of 9.81m/s. When the TWR was 2, acceleration would be 19.62 and so on.

Then, the time to impact is calculated. It's definetely not correct, because it does not take into account the aerodynamic drag, but for the program it is perfectly suited. It's simply calculated by taking our current altitude above ground and dividing that by the -verticalspeed to get an estimate.

Knowing our acceleration, the last and most important step is then to divide the -verticalspeed / acceleration. This is stored in the variable burntime, which simply says how long our suicide burn will be. Then, a simple "if-loop" triggers the engine. "If the time to impact < burntime, fire up the engine". "Else, shut it down".

That's it. But it took me quite a while to figure the best way out.

 

I am right now improving the program, for example it has now a rough estimation included how much fuel will be used in the suicide burn. This way, the program will automatically stop me from further ascending if I don't have enough fuel for landing.

 

I've integrated the code now into my grasshopper code:

 

I will now redo the required fuel formula, making it much more precise.

Steering is something I will consider to in the future.

Link to comment
Share on other sites

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