[KSP 1.12.x] kOS v1.4.0.0: kOS Scriptable Autopilot System

[kcs123]

44 minutes ago, squidgeny said:

Thanks both! It sounds like a "boot file" is what I want. I think I've found the relevant bit in the docs: https://ksp-kos.github.io/KOS_DOC/general/volumes.html#special-handling-of-files-in-the-boot-directory

If I understand this correctly (and i probably don't, because the docs are way beyond my layman knowledge!), I need to do the following:

• create a "boot" directory on the ship's CPU volume, and put my program in it
• switch to the vessel (thus causing the program to begin running immediately) before it reaches the relevant point where a manoeuvre needs to be made
• sit back and wait for the program to execute all its code
• then I can safely switch out to another vessel / space centre or whatever

If I've got that right then that's more than good enough

Pretty much like that. Although, there is no need to put whole main program in boot directory. You can rather use something smal with just few lines of code in boot file and from there just execute main script. Example:

Spoiler

wait until ship:unpacked.
if ship:status = "PRELAUNCH" {
	if not exists("/lib_navball")
	{
		copypath("0:/lib/lib_navball","").
	}.
	if not exists("/interpolation_lib")
	{
		copypath("0:/lib/interpolation_lib","/interpolation_lib").
	}.
	if not exists("/re_launch_gui")
	{
		copypath("0:/Relay_LKO_EQ/re_launch_gui","").
	}.
	runpath("/re_launch_gui",90,160000,57). // HG-5 Relay equator
}.
if ship:status = "ORBITING" {
	if exists("/interpolation_lib")
	{
		deletepath("/interpolation_lib").
	}.
	if exists("/re_launch_gui")
	{
		deletepath("/re_launch_gui").
	}.
	if not exists("/science_lib")
	{
		copypath("0:/lib/science_lib","").
	}.
		if not exists("/sci_gui")
	{
		copypath("0:/Relay_LKO_EQ/sci_gui","").
	}.
	runpath("/sci_gui").
	
}.

 

It is highly recommanded that you use following command as first line in boot script as otherwise rest of the code can fail for various reasons if craft is not unpacked yet:

Quote

wait until ship:unpacked.

In example above, my boot script check ship status and on launchpad it copy necessary library files and run main program to put rocket in orbit. Once ship is in orbit, if I revisit it second time and still have comm established, script check for files that are on craft internal HDD and delete/copy other files that are used in orbit. Usualy it is either, to execute maneuver node or like in case above to run script that run science experiment and transmit or collect science over various biomes.

You may also want to write current status of your mission in some file and based on that run specific script or part of script. Whatever you want or need.

[infinite_monkey]

I'm having some hickups with locked variables:

lock steer to lookdirup(ship:up:forevector, ship:facing:topvector).
lock steering to steer.

Later, I do

set steer to heading(hdg, ang).

which sometimes, but not always, fails due to "Undefined Variable Name 'steer'". Why is that?

[Drew Kerman]

13 minutes ago, infinite_monkey said:

I'm having some hickups with locked variables:

lock steer to lookdirup(ship:up:forevector, ship:facing:topvector).
lock steering to steer.

Later, I do

set steer to heading(hdg, ang).

which sometimes, but not always, fails due to "Undefined Variable Name 'steer'". Why is that?

try doing unlock steer before using the set. I had a similar issue but the other way around where I defined a variable with set then later tried to lock it

wait are you trying to change the direction of the locked steering? Then you should just keep using lock.

Edited October 9, 2019 by Drew Kerman

[infinite_monkey]

9 minutes ago, Drew Kerman said:

try doing unlock steer before using the set. I had a similar issue but the other way around where I defined a variable with set then later tried to lock it

wait are you trying to change the direction of the locked steering? Then you should just keep using lock.

Yes, I'm trying to change direction. Since I'm doing that in a loop, I thought I could as well use set. Interestingly, it works if I print steer just before writing to it...

 

[Drew Kerman]

1 hour ago, infinite_monkey said:

Since I'm doing that in a loop, I thought I could as well use set

oh I get it. But you can still use lock for steer and then use set to change hdg and ang as necessary. that's what I do

gah wait no I mean I do lock steering to heading(hdg, pitch) - you don't need a separate steer variable - unless you plan to update the steering model again later I suppose

Edited October 9, 2019 by Drew Kerman

[infinite_monkey]

9 minutes ago, Drew Kerman said:

oh I get it. But you can still use lock for steer and then use set to change hdg and ang as necessary. that's what I do

gah wait no I mean I do lock steering to heading(hdg, pitch) - you don't need a separate steer variable - unless you plan to update the steering model again later I suppose

Good catch, thanks!

[danielboro]

15 hours ago, squidgeny said:

Thanks both! It sounds like a "boot file" is what I want. I think I've found the relevant bit in the docs: https://ksp-kos.github.io/KOS_DOC/general/volumes.html#special-handling-of-files-in-the-boot-directory

If I understand this correctly (and i probably don't, because the docs are way beyond my layman knowledge!), I need to do the following:

• create a "boot" directory on the ship's CPU volume, and put my program in it
• switch to the vessel (thus causing the program to begin running immediately) before it reaches the relevant point where a manoeuvre needs to be made
• sit back and wait for the program to execute all its code
• then I can safely switch out to another vessel / space centre or whatever

If I've got that right then that's more than good enough

grate source of knowledge
just be carfol some of it uses old KOS and cant run on version 1

 

Edited October 10, 2019 by danielboro

[zer0Kerbal]

@SpinkAkron

https://www.youtube.com/channel/UC8rKwFBhWhGhid-PO5iSP4A

[kcs123]

8 hours ago, danielboro said:

grate source of knowledge
just be carfol some of it uses old KOS and cant run on version 1

Agree on that. Highly recommended to watch. Some pieces of kOS code might be obsolete, but Kevin explain a lot of other good stuff, regading physics and alghoritam used in general that could be easy adjusted for other usage.One of his videos inspired me to create interpolation calculation library instead of using pre-made formula from web site for each mission. You can find it somewhere buried in this thread if you want to use that one for optimal ascending path to orbit for your crafts.

SpinkAkron also have some good examples. I borrowed his science collection script and adjusted for personal usage with additional feature to store experiments instead of transmiting and with GUI interface, for example.

[SiRCrashaLot]

 

Hello, I am sure this has been asked but as I scour I cannot find..

I am looking to balance the thrust between 2 VTOL engines. The goal is to maintain level (straight) flight/hover at a specified altitude or increase/decrease altitude. I have found a few scripts out there but they don't seem to do the trick or are hand tailored for specific scenarios. I would like to use a combo of SAS/Reaction Wheels and Thrust to maintain the overall profile. I guess basically how do I maintain pitch 0 with 2 engines forward and aft that are not quite balanced?

Or an alternative if someone knows which one, a way to convert the hover functionality in TCA to KOS friendly. Any help is greatly appreciated.. Have a great day.. the video below is my feebles… one engines is set to 64 and the other 100.. works for one TO and landing of course. My prior video above..

[squidgeny]

On 10/9/2019 at 5:47 PM, kcs123 said:

Pretty much like that. Although, there is no need to put whole main program in boot directory. You can rather use something smal with just few lines of code in boot file and from there just execute main script.

Hmm I think I must be doing something wrong. I decided to test this by creating a new program (in fact, the only program) on my probe's kOS device called "test", which i placed in a "boot" folder ("1:/boot/test").

The code is super simple:

wait until ship:unpacked.
Lock STEERING to SHIP:RETROGRADE.
wait 3.
unlock steering.

Then I went back to the tracking station, and then I went back to the probe. I expected it the run the program and cause the probe to rotate to face retrograde, but nothing happened. SAS is on and the probe has power and a reaction wheel, so what went wrong? I assume it's something simple and I'm being an idiot!

Edited October 12, 2019 by squidgeny

[SiRCrashaLot]

On 7/13/2019 at 8:04 AM, Kartoffelkuchen said:

Slowly getting good enough for a release I think.

So much new stuff has been added and remade since the last video, a much better & smoother pitch control logic, a glideslope control logic which makes sure the plane stays roughly in the desired glideslope, a new landing "flare mode" trigger, which contributes to overall much more accurate and smoother landings. Also some more safety features have been added, for example bank angle & pitch limits, a ground-proximity-warning-system (you can see the warnings in the video, however system was not activated because the plane was in a lanidng configuration), flight prediction and terrain scanning and of course also a rule to disable some of these systems in case of a detected emergency, kind of like an alternate flight law in an Airbus. Really like how this is coming along, crazy that it's been over a year since I started this project.

 

Interested in what you are using for flight path angle and also altitude or round out for the flare.

My Descent Angle is this:

Function AngleDescent
{
set vdescangle to 3. // 3 degree glide slope
local vknots is round(airspeed*1.94384). //convert meters to knots
//local fpm is vknots*5. //3 degrees roughly.
local fpm to vdescangle/60 * vknots/60 * 6080. // convert to feet per minute
local mpm is fpm/3.280834. // convert to meters per minute
local mps is mpm/60. // convert to meters per second
return mps. // vertical speed variable to maintain glide slope.
}    

 

[scimas]

7 hours ago, squidgeny said:

SAS is on

1. SAS should be off if you're using kos' steering. Or they will fight each other.

2. Simply placing a file in the boot directory isn't enough, you need to point the bootfile to your program too. Either you do that via VAB / SPH when building the ship or manually via the terminal when in flight:

set core:bootfilename to "/path/to/program".

From next time, that program will run automatically.

Also, I would change the first line to

wait until SHIP:LOADED and SHIP:UNPACKED.

I have seen sometimes that using just one of them isn't enough.

[kcs123]

10 hours ago, squidgeny said:

Then I went back to the tracking station, and then I went back to the probe. I expected it the run the program and cause the probe to rotate to face retrograde, but nothing happened. SAS is on and the probe has power and a reaction wheel, so what went wrong? I assume it's something simple and I'm being an idiot!

It is good to start with very simple program for start. You could also want to do something even more simple, just to print something on console.

I'm just guessing here, but I think that you forgot to choose in VAB, at kOS CPU part, what program will be run when you launch craft. It is not enough just to copy file to boot directory of craft, you also need to tell it to run it. Most simple way is to choose it in VAB, but there is also command to change it when your craft is launched. I forgot exact syntax from top of my head, but example should be possible to find in this thread because I asked same thing long time ago.

Anyhow, it might be good to check official documentation about it: http://ksp-kos.github.io/KOS_DOC/general/volumes.html#special-handling-of-files-in-the-boot-directory

EDIT:

I should read other people post before answering, @scimas already wrote this:
 

Quote

2. Simply placing a file in the boot directory isn't enough, you need to point the bootfile to your program too. Either you do that via VAB / SPH when building the ship or manually via the terminal when in flight:

set core:bootfilename to "/path/to/program".

 

Edited October 13, 2019 by kcs123

[squidgeny]

It worked! Thank you both! It now runs when I load the ship  I feel like the Docs really ought to have the "set core:bootfilename" because I don't know how I would have found that out otherwise. Thank god for this thread. Is there a more comprehensive glossary/manual than the https://ksp-kos.github.io website?

Anyway, now I have another problem though, and I've spent 30mins googling this but to no avail! My "Lock STEERING to SHIP:RETROGRADE." command is, er, a bit chaotic. The ships spins around wildly. It looks like it's trying to point retrograde but never settles, even if I bump the "wait" command up to 2 minutes before unlocking the steering. The odd thing is, is that if I use "Lock STEERING to HEADING(90,0)" it has no problem - it rotates to face that heading on the navball, and then stops rotating, in just a few seconds.

I dunno if it's a bug (can't find anyone with the problem through google), but it looks like what I need to do is write some code that gets the retrograde co-ordinates and turns it into a heading() command. Trouble is, I can't find out how to do that either!

I managed to find the commad "SET SASMODE TO "RETROGRADE"." in a PDF somewhere, but sadly my probe is just an OKTO and doesn't have that ability.

In retrospect, given that my probe doesn't have the ability to set SAS to retrograde, I shouldn't be able to program it to do so anyway

Edited October 21, 2019 by squidgeny

[zer0Kerbal]

5 hours ago, scimas said:

set core:bootfilename to "/path/to/program".

I think I have that written on a well used postitnode - somewhere.

[Kartoffelkuchen]

14 hours ago, SiRCrashaLot said:

Interested in what you are using for flight path angle and also altitude or round out for the flare.

My Descent Angle is this:

Function AngleDescent
{
set vdescangle to 3. // 3 degree glide slope
local vknots is round(airspeed*1.94384). //convert meters to knots
//local fpm is vknots*5. //3 degrees roughly.
local fpm to vdescangle/60 * vknots/60 * 6080. // convert to feet per minute
local mpm is fpm/3.280834. // convert to meters per minute
local mps is mpm/60. // convert to meters per second
return mps. // vertical speed variable to maintain glide slope.
}    

 

What you have there is just a "static" approach angle, the plane will always follow this 3° glideslope, even if this glideslope won't lead the plane to the runway and make it under- or overshoot. What you instead want is a more "dynamic" way of calculating the angle, you really want to hit that runway, so what you'll need to do is make the angle based on the runway distance and your current altitude. Here's mine:

SET descentangle to -arctan((altitude-height-runwaypos:terrainheight) / max((grounddistance - 1000),0.0001)).

So what we've got here is calculating the angle by using the current altitude of the airplane - the height of the plane (probably unnecessary here but I'm still doing it) - the height of the terrain at our target landing position and dividing that by the distance to the runway on the ground. I guess you could also use cos and then just use the runwaypos:distance instead of having to make some wonky calculations to get the actual distance on the ground but that's what I decided to settle on. Using the -1000 btw so that we're actually targeting a spot 1000m ahead of the runway so we don't overshoot too much since we won't follow that angle anymore once we're flaring.

As for the flare, this is the line that triggers the switch from the descent to flare mode:

SET flareInit_alt to abs(descentangle) * 50 + 50.

Basically just trial and error to see what works best lol. Condition for the switch from descent to flare is then:

IF altitude-height - runwaypos:terrainheight < flareInit_alt
{
	SET autoland_mode to "flare".
	SET lastdescentangle to descentangle.
}
                                                            
ELSE IF autoland_mode = "flare" AND landingabort = 0
{	
	SET descentangle2 to -arctan((altitude-height-runwaypos:terrainheight) / max(grounddistance,0.0001)).
	SET flare_agg to max( min( 0.01 / descentangle * (-1000),-0.15), -0.3).
	SET holdpitch_param to max(min((altitude-height-targetrunway[1]:terrainheight)*(flare_agg),-1),min(descentangle2,-1)).
}
                                                            

Notice I'm now using the actual runway position, not -1000. I've got that one factor flare_agg in there, since the plane won't be able to immediately change it's pitch angle and that factor basically just controls how quickly the pitch angle will be reduced in order to prevent us crashing into the ground because we didn't flare soon enough. Last line then just controls the actual pitch angle we'll follow, also using the  descentangle2 so that we will not descent with a higher angle than we prreviously had before we switched to flare mode.

It's really just some really basic triangly maths and then figuring out which limitations and factors you'll need to introduce to have a safe approach which the plane can follow nicely.

I also have a second option to use which lets you specify an angle you'll want to follow, like 3deg. Then based on that the plane will adapt it's pitch angle constantly to try to follow that 3deg glideslope, so if you had a 8deg angle with the method I mentioned above, the plane will pitch down more to like 12deg so that the angle reduces and then eventually pitch up at the right time to follow that 3deg glideslope again but I guess what I wrote above is enough for a start.

Edited October 13, 2019 by Kartoffelkuchen

[scimas]

6 hours ago, squidgeny said:

Is there a more comprehensive glossary/manual

The documentation is very comprehensive. KOSPROCESSOR:BOOTFILENAME is literally the third search result for "boot" in a total of four results..

6 hours ago, squidgeny said:

My "Lock STEERING to SHIP:RETROGRADE." command is, er, a bit chaotic.

That depends on what situation your ship is in. If you're moving at a very slow speed, then it is highly likely that the retrograde direction is moving around wildly. Whereas heading(90, 0) is more or less a fixed direction. And I repeat again, SAS has to be off if you're using kos' cooked steering.

[SiRCrashaLot]

6 hours ago, Kartoffelkuchen said:

What you have there is just a "static" approach angle, the plane will always follow this 3° glideslope, even if this glideslope won't lead the plane to the runway and make it under- or overshoot. What you instead want is a more "dynamic" way of calculating the angle, you really want to hit that runway, so what you'll need to do is make the angle based on the runway distance and your current altitude. Here's mine:

SET descentangle to -arctan((altitude-height-runwaypos:terrainheight) / max((grounddistance - 1000),0.0001)).

Look Here --->

Hello, Thanks for the response.. The code I have does indeed smash you down to the runway.. however if you speed up or slow down it maintains the static angle. I did prior to this measure the distance to the runway and height and did a rough calculation. I basically said to maintain a 3 degree angle to a runway I must be at x altitude.

It works great and I am trying to maintain "real life" as much as possible.. I did something like your dynamic before it worked by ensuring you would reach point x by a certain time based on airspeed. So it would follow a variable glide slope.

My flare was along the lines of if you are 14 meters off the deck when you reach the runway .. flare..

My other option was using old code that would say if you are under 100+alt:radar and you are right before the runway .. flare ..

The issue I have is fuel consumption and weight. I am not sure how to calculate when to flare based on the changing characteristics of the flight.. the only sure fire way is fuel dump to achieve a weight that will ensure a perfect (mostly) flare.

So what we've got here is calculating the angle by using the current altitude of the airplane - the height of the plane (probably unnecessary here but I'm still doing it) - the height of the terrain at our target landing position and dividing that by the distance to the runway on the ground. I guess you could also use cos and then just use the runwaypos:distance instead of having to make some wonky calculations to get the actual distance on the ground but that's what I decided to settle on. Using the -1000 btw so that we're actually targeting a spot 1000m ahead of the runway so we don't overshoot too much since we won't follow that angle anymore once we're flaring.

As for the flare, this is the line that triggers the switch from the descent to flare mode:

SET flareInit_alt to abs(descentangle) * 50 + 50.

I will try these out.. I think my weight issue is going to continue to be an issue? maybe..

Basically just trial and error to see what works best lol. Condition for the switch from descent to flare is then:

IF altitude-height - runwaypos:terrainheight < flareInit_alt
{
	SET autoland_mode to "flare".
	SET lastdescentangle to descentangle.
}
                                                            
ELSE IF autoland_mode = "flare" AND landingabort = 0
{	
	SET descentangle2 to -arctan((altitude-height-runwaypos:terrainheight) / max(grounddistance,0.0001)).
	SET flare_agg to max( min( 0.01 / descentangle * (-1000),-0.15), -0.3).
	SET holdpitch_param to max(min((altitude-height-targetrunway[1]:terrainheight)*(flare_agg),-1),min(descentangle2,-1)).
}
                                                            

Notice I'm now using the actual runway position, not -1000. I've got that one factor flare_agg in there, since the plane won't be able to immediately change it's pitch angle and that factor basically just controls how quickly the pitch angle will be reduced in order to prevent us crashing into the ground because we didn't flare soon enough. Last line then just controls the actual pitch angle we'll follow, also using the  descentangle2 so that we will not descent with a higher angle than we prreviously had before we switched to flare mode.

It's really just some really basic triangly maths and then figuring out which limitations and factors you'll need to introduce to have a safe approach which the plane can follow nicely.

I also have a second option to use which lets you specify an angle you'll want to follow, like 3deg. Then based on that the plane will adapt it's pitch angle constantly to try to follow that 3deg glideslope, so if you had a 8deg angle with the method I mentioned above, the plane will pitch down more to like 12deg so that the angle reduces and then eventually pitch up at the right time to follow that 3deg glideslope again but I guess what I wrote above is enough for a start.

 

[squidgeny]

21 hours ago, scimas said:

That depends on what situation your ship is in. If you're moving at a very slow speed, then it is highly likely that the retrograde direction is moving around wildly. Whereas heading(90, 0) is more or less a fixed direction. And I repeat again, SAS has to be off if you're using kos' cooked steering.

In this case my probe is currently on its way to Minmus on a very long arc that'll take several days. The retrograde direction is moving, but imperceptibly slow (5 degrees a day, or thereabouts). I have my program switch off SAS before it tries to point retrograde (I tried it with both SAS on and off actually, but similar results in both cases)

I'll see if I can film it and post a video.

[SiRCrashaLot]

 

 

[SiRCrashaLot]

Is this broken or a feature? There is the main throttle and independent throttle. When I query the module ModuleEngineFX it says there are 2 "throttle" settings.. 1 to determine if the separate throttle is on. the 2nd being the setting for the independent throttle. How does on determine which is which?

 

        local m is s:getModule("ModuleEnginesFX").
   
        M:Setfield("Throttle",False).

        M:Setfield("Throttle",100).

both work but only 1 actually does anything..

any ideas?

 

 

[RizzoTheRat]

Gah, ignore me.  Was having path prediction problems fixed it now and can't work out how to delete a post

Edited October 18, 2019 by RizzoTheRat

[Dunbaratu]

@Matt Stryker posted this in a different thread - I'm replying to it here:

Quote

I have a very simple script for auto landing  that is now giving me an error that says, "undefined variable name 'verticalspeed'"

Here's the line that breaks (and I assume all other lines that check verticalspeed)

until verticalspeed>=0

Like I said, this used to work perfectly.  I don't know enough about programming in KOS to program around this.

Are you running this on KSP 1.8?  If so, then kOS is almost completely broken on KSP 1.8 and that's the problem you're having.  All of kOS's bound variables are missing in KSP 1.8 - verticalspeed, core, ship, velocity, apoapsis, etc.  I know why and fixed it in the develop branch but there's other problems with the KSP 1.8 update I need to fix first before I release a kOS that's compatible with KSP 1.8.

(Without going into too much detail, the problem was apparently caused by a very subtle difference in how "Reflection" does things in the newer C#/.Net, causing some Types to be "Equal" which were not "Equal" before.  kOS was storing information about these Types in a collection that requires unique keys and this change meant they weren't unique anymore.)

[Matt Stryker]

Oh, okay then!  Thank you for working on this so quickly!  I was rather proud of my simple little program that worked pretty well for auto-landing booster tanks and engines for re-use, then POOF.  1.8 killed it.