[1.3] kOS Scriptable Autopilot System v1.1.3.0

[hvacengi]

18 hours ago, dewin said:

So, if I want the most accurate calculations, should I be going off the values of obt or ship?  The former seems to be slightly ahead of the latter.

I would expect (however I have not yet confirmed) that the vessel's velocity suffix is more accurate than the obt suffix.  The velocity suffix reads the value directly off of the ship's current properties.  The orbit structure however returns the result of GetVelocityAtUT for the current time, which uses predictive methods rather than reading raw properties.  That means that there are more opportunities for errors (due to a combination of additional calculation steps, and probably at least one run through a newton solver).  It also means that obt:velocity should be substantially slower for the underlying execution.

We may want to evaluate that implementation in the future though.  We'll have to look at why it's implemented the way it is.

Edited May 31, 2016 by hvacengi

[dewin]

1 hour ago, hvacengi said:

I would expect (however I have not yet confirmed) that the vessel's velocity suffix is more accurate than the obt suffix.  The velocity suffix reads the value directly off of the ship's current properties.  The orbit structure however returns the result of GetVelocityAtUT for the current time, which uses predictive methods rather than reading raw properties.  That means that there are more opportunities for errors (due to a combination of additional calculation steps, and probably at least one run through a newton solver).

This is what I initially suspected as well, but it doesn't explain the magnification of error on timewarp.  And, judging by my log of velocity magnitudes up above, the obt velocity is extremely close to the NEXT update's vessel velocity.  This is what leads me to believe that kOS updates before the ship properties do.

GetVelocityAtUT should require exactly one pass through a newton solver -- in calculating the eccentric anomaly (needed to calculate true anomaly).  I'm actually implementing the same thing in kOS using a custom lexicon to be able to do things like... predict the outcome of a series of maneuvers prior to actually creating maneuver nodes (by creating my structure from an obt, shifting it to a maneuver time, altering the velocity, and creating a new structure from the position and velocity vectors.)

In my own testing, eccentric anomaly can be determined to a precision of 1E-15 in 57 iterations worst-case (average was 55 iterations).  There's some tricks that can reduce this: I have a Python script that precomputes a table of results for anomalies 0<M<=180 and dumps the results to a .ks file.  (Parsing the file locks up KSP for about 5 minutes but the compiled version is instant so it is a one-time deal).  The kOS-side solver uses the table to determine its starting values.  (Anomalies for M>180 are 360-f(360-M))

[hvacengi]

9 minutes ago, dewin said:

This is what I initially suspected as well, but it doesn't explain the magnification of error on timewarp.  And, judging by my log of velocity magnitudes up above, the obt velocity is extremely close to the NEXT update's vessel velocity.  This is what leads me to believe that kOS updates before the ship properties do.

I don't know at which point the current UT is advanced.  If UT advances at the beginning of FixedUpdate it is possible that the predictive method is returning the value that will be set (but not really) when the physics calculation is done following the part module FixedUpdate and autopilot methods.  In that case, the orbit's velocity suffix should return the next tick's velocity, ignoring drag, vessel rotation, part wobble, RCS thrust, engine thrust, and any other forces or torques outside of gravity.  In which case, there may be a few fringe cases where reading the velocity a frame early, even if less accurate, would be useful.

If the system UT is advanced at the same time as calculating physics, then it's just error in the KSP api, and pinpointing exactly where becomes difficult.

[dewin]

The UT advance happening at the start would explain the behavior during timewarp, where error values are multiplied by very close to the warp multiplier and none of the other forces are in effect.  I'm going to theorize on that being the case and go with it.

(Now if I could just figure out the correct Y value for a given orbit and time without : position I'll be set.  My existing approach is... not correct).

[CoriW]

Just wondering, is anybody else having problems getting the kOS button to show up on Blizzy's Toolbar? I tell it to use Blizzy's Toolbar, but it doesn't show up in the "Configure Visible Buttons" list on the toolbar.

[Bosun]

Question - 

 

Just decided to give this mod a try.  I'm not code-savvy too much yet, but I'm learning.  


Problem:  I build the ship in the first tutorial on the GIthub page.  I go to the launchpad, I have the script from the tutorial.   When I execute the HelloLaunch program, it Sets throttle to full, counts down, sets throttle to 1/3, and stages, while also unlocking steering (because if I manually boost the throttle, the ship does not steer.) 

I did some testing.   Turns out, if I type:

Lock Throttle to 1.0. //this locks the throttle to full.  Good so far.

Lock Steering to Up. //this may lock the steering, not sure, but it does knock the throttle back down to 1/3, also causing me to be UNABLE to re-lock the throttle.  IE - Once the command is typed once for the ship, I can no longer affect the throttle in the program, and the program effectively ceases.

Anyone else encounter this?  

[Drew Kerman]

8 hours ago, CoriW said:

Just wondering, is anybody else having problems getting the kOS button to show up on Blizzy's Toolbar? I tell it to use Blizzy's Toolbar, but it doesn't show up in the "Configure Visible Buttons" list on the toolbar.

Yep, I see that as well

[hvacengi]

5 minutes ago, Bosun said:

Lock Steering to Up. //this may lock the steering, not sure, but it does knock the throttle back down to 1/3, also causing me to be UNABLE to re-lock the throttle.  IE - Once the command is typed once for the ship, I can no longer affect the throttle in the program, and the program effectively ceases.

This more than likely means you are using the most recent release with an older version of KSP.  The most recent version will error on any version of KSP earlier than 1.1.2, and that manifests itself by preventing kOS from being able to update any of the controls.

Please verify your version numbers, and report them here if updating does not fix the problem.

[Bosun]

Ahhhhh, ok, thanks.  

 

[DaMachinator]

What unit does VESSELSENSORS:PRES return its data in, and has this changed since KSP 1.0.x?

For now, I am working on the assumption that it is the same unit that the Presmat displays data in when you "toggle display".

[MAFman]

On 5/29/2016 at 8:20 PM, Steven Mading said:

To obtain the slope of an area, you first obtain the normal vector to the "terrain plane" of that area.

To get the normal vector to the terrain plane, take 3 sample 3-D positions nearby each other (that aren't all in a straight line), labelled in clockwise order, A, B, and C.  The normal of the terrain plane at A is:

local norm is VCRS( (B - A, (C - A) ).

The angle between that normal and straight up at position A is the slope angle of the terrain there.
 

local terrain_bank_angle is VANG(norm, (A - the_body:position) ).

 

A bit too math-y for my overtired mind at the moment, but I like that idea, and I'll have to investigate later!

On 5/22/2016 at 5:18 AM, Gaiiden said:

https://github.com/Gaiiden/RoverDriver

Note this was written in pre v1.0 compatible kOS script but it's a start. Doesn't navigate itself tho, was designed to follow pre-plotted waypoints based off SCANsat terrain data once a planet was mapped

Can you help me update the code so it works in 1.1.4 or whatever the current KSP version is, and so that I can just input a latitude and longitude pair for the waypoints instead of needing to use vessels?

[CoriW]

Hello, so I went through the quickstart on the kOS documentation page (here) and have been messing around with modifying the launch script and I've been having a strange problem with it. The rocket I've been using is fairly simple, the center stack has 2 stages (bottom stage has a swivel engine, top stage has a terrier engine) then there are 2 liquid fuel boosters (with reliant engines) on the sides. (no fuel lines, haven't unlocked them yet) The staging is setup to have the boosters lift the vessel until they run out of fuel, and then when the boosters decouple the center stack (swivel) ignites. (Note: The rocket also has winglets so it has steering authority when just the boosters are firing)

Alright so first I'll show the script, then I'll explain the problem.

CLEARSCREEN.

SET desAlt TO 55000.
SET currRoll TO 0.

SET mysteer TO R(0,0,-90) + HEADING(90,90 - currRoll).

LOCK STEERING TO mysteer.
LOCK THROTTLE TO 1.0.

PRINT "Counting Down:".
FROM {LOCAL countdown IS 5.} UNTIL countdown = 0 STEP {SET countdown TO countdown - 1.} DO {
	PRINT "..." + countdown.
	WAIT 1.
}

WHEN STAGE:LIQUIDFUEL < 0.1 THEN {
	PRINT "STAGE.".
	STAGE.
	PRESERVE.
}

WAIT UNTIL SHIP:VELOCITY:SURFACE:MAG > 100.

UNTIL SHIP:APOAPSIS > 75000 {
	
	IF SHIP:ALTITUDE <= desAlt AND SHIP:ALTITUDE > (desAlt / 90) * currRoll AND currRoll < 90 {
		SET currRoll TO currRoll + 1.
		SET mysteer TO R(0,0,-90) + HEADING(90,90 - currRoll).
	}
	
	PRINT "ROLL PROGRAM " + (90 - currRoll) AT (20,0).
}

The problem: Alright so as you can see from the script, I use an equation in order to setup various altitudes at which the pitch of the rocket will decrease by 1 degree, in order to create a smooth gravity turn which ends at the "desAlt" value. However what ends up happening is the rocket will go straight up until it stages and the boosters decouple, at which point it will rapidly pitch down until it reaches the pitch angle which matches the "currRoll" value specified in the script. The first thing I though was happening was that the "currRoll" variable wasn't being updated correctly, so I told it to print what the current "currRoll" value was to the console and sure enough, it was updating correctly as the altitude increased.

Once I determined the script was updating correctly, and that the rocket simply wasn't doing what it should have been, I thought that I should try replacing the reliant engines on the booster with swivel engines. This of course would make the thrust to weight ratio for the boosters not strong enough to lift the rocket so I had to make the booster tanks a bit smaller. After doing this, the rocket started to obey the "currRoll" variable set in the script and steer accordingly (which doesn't make sense because the winglets should have provided enough steering control when the boosters had reliants on them.)

So anyways, at this point the rocket seemed to follow the script perfectly... until it staged the boosters, at which point it just seemed to lock the steering to the point it was at when the staging event happened. After about 10 or 15 seconds suddenly pitched down to match the current "currRoll" variable, and continued to follow it after this point.

To be honest I don't understand why this is happening, because the variables that the steering is locked to "mysteer" is properly being updated, but at points the rocket just doesn't seem to want to obey what the script is telling it to do, and just locks to whatever it is currently set to until either the rocket stages, or for some questionably defined period of time after staging.

Edited June 5, 2016 by CoriW

[Drew Kerman]

11 hours ago, MAFman said:

Can you help me update the code so it works in 1.1.4 or whatever the current KSP version is, and so that I can just input a latitude and longitude pair for the waypoints instead of needing to use vessels?

That's not something I would be interested in programming BUT of course if you come here with any questions I and others will be happy to help out

[Jim DiGriz]

3 hours ago, CoriW said:

Once I determined the script was updating correctly, and that the rocket simply wasn't doing what it should have been, I thought that I should try replacing the reliant engines on the booster with swivel engines. This of course would make the thrust to weight ratio for the boosters not strong enough to lift the rocket so I had to make the booster tanks a bit smaller. After doing this, the rocket started to obey the "currRoll" variable set in the script and steer accordingly (which doesn't make sense because the winglets should have provided enough steering control when the boosters had reliants on them.)

So anyways, at this point the rocket seemed to follow the script perfectly... until it staged the boosters, at which point it just seemed to lock the steering to the point it was at when the staging event happened. After about 10 or 15 seconds suddenly pitched down to match the current "currRoll" variable, and continued to follow it after this point.

That sounds like you're trying to generate too large of an angle-of-attack and the aerodynamics is not letting you.  Once you hit a high enough velocity in thick enough atmosphere, with a properly shaped dart-like rocket you'll wind up getting forced into a roughly zero AoA gravity turn anyway.  If you haven't pitched over far enough at that point you'll tend to go straight up, if you've pitched over way too far you can find your rocket turning over and starting to head down with nothing that you can do about it.  But then once you clear the think part of the atmosphere you regain control and it pitches over.

Generally what works better is to pitch over 10-15 degrees to initiate a turn, then wait for your AoA to get large and then get small again, then lock your steering to your surface velocity vector.

[CoriW]

1 hour ago, Jim DiGriz said:

That sounds like you're trying to generate too large of an angle-of-attack and the aerodynamics is not letting you.  Once you hit a high enough velocity in thick enough atmosphere, with a properly shaped dart-like rocket you'll wind up getting forced into a roughly zero AoA gravity turn anyway.  If you haven't pitched over far enough at that point you'll tend to go straight up, if you've pitched over way too far you can find your rocket turning over and starting to head down with nothing that you can do about it.  But then once you clear the think part of the atmosphere you regain control and it pitches over.

Generally what works better is to pitch over 10-15 degrees to initiate a turn, then wait for your AoA to get large and then get small again, then lock your steering to your surface velocity vector.

Oh also another important bit of information.. When the rocket locks the steering, if I end the script and try to turn manually.. It turns just fine. So unfortunately that can't be the problem.

[Dunbaratu]

9 minutes ago, CoriW said:

Oh also another important bit of information.. When the rocket locks the steering, if I end the script and try to turn manually.. It turns just fine. So unfortunately that can't be the problem.

The important trick is to keep your eyes on the lower-left of the screen during the problem part to watch what the pitch, yaw, and roll control sliders are doing during the part where the ship should be turning but isn't.

If those controls are trying to command a deflection but nothing is happening, then the blame is with the rocket design.   If those controls aren't even trying to command a deflection and are staying centered, then the blame is with the program or with kOS.  To further tell if it's the script or if it's kOS, store the `heading(a,b)` thing in a variable that you can print.  If the printout shows a desired heading utterly different from what you're getting, and the controls aren't moving, then it's kOS's fault.  If the printout shows the heading isn't what you wanted, then it's the script's fault.

 

 

[Jim DiGriz]

2 hours ago, CoriW said:

Oh also another important bit of information.. When the rocket locks the steering, if I end the script and try to turn manually.. It turns just fine. So unfortunately that can't be the problem.

I've seen weird things with variable scoping and 'lock'.

If you remove the `lock heading` and just set the heading in the loop does it work?  Alternatively, if you declare mysteer as either global or local explicitly does that fix it?

EDIT: and yeah, one obvious symptom of this would be that the controls in the bottom right wouldn't be trying to respond at all.

Edited June 5, 2016 by Jim DiGriz

[CoriW]

2 hours ago, Steven Mading said:

The important trick is to keep your eyes on the lower-left of the screen during the problem part to watch what the pitch, yaw, and roll control sliders are doing during the part where the ship should be turning but isn't.

If those controls are trying to command a deflection but nothing is happening, then the blame is with the rocket design.   If those controls aren't even trying to command a deflection and are staying centered, then the blame is with the program or with kOS.  To further tell if it's the script or if it's kOS, store the `heading(a,b)` thing in a variable that you can print.  If the printout shows a desired heading utterly different from what you're getting, and the controls aren't moving, then it's kOS's fault.  If the printout shows the heading isn't what you wanted, then it's the script's fault.

 

 

 

44 minutes ago, Jim DiGriz said:

I've seen weird things with variable scoping and 'lock'.

If you remove the `lock heading` and just set the heading in the loop does it work?  Alternatively, if you declare mysteer as either global or local explicitly does that fix it?

EDIT: and yeah, one obvious symptom of this would be that the controls in the bottom right wouldn't be trying to respond at all.

Alright I've checked and the controls aren't even trying to move to the new heading... They just seem to stop in a fixed direction for awhile, and then they resume at some point later. The "currRoll" variable is updating correctly, which means the problem has to be something with the steering locking to the "currRoll" variable. I'll try setting the heading in the loop instead of locking it as @Jim DiGriz suggested, and report back.

[Alchemist]

Sometimes when control authority is low the steering manager seems to try wat too hard to avoid overcorrection.

Try looking into this http://ksp-kos.github.io/KOS_DOC/commands/flight/cooked.html#tuning-cooked-steering

 

[hvacengi]

20 hours ago, CoriW said:

Alright I've checked and the controls aren't even trying to move to the new heading... They just seem to stop in a fixed direction for awhile, and then they resume at some point later. The "currRoll" variable is updating correctly, which means the problem has to be something with the steering locking to the "currRoll" variable. I'll try setting the heading in the loop instead of locking it as @Jim DiGriz suggested, and report back.

My first note would be to add a `wait 0.` command at the bottom of you `until` loop.  As it stands, your loop is running continuously and not waiting for the physics to tick to the next frame.  That means you might be updating the direction before the ship actually moves towards the new direction.  It also means that your altitude doesn't have time to change in between iterations.  This shouldn't fix your problem unless we have a bug in how kOS handles mainline code vs trigger code (`lock steering` and `when` blocks are triggers).

I'm a little confused by the intention of your logic here:

SET currRoll TO currRoll + 1.
SET mysteer TO R(0,0,-90) + HEADING(90,90 - currRoll).

The heading function takes parameters of compass heading and pitch above horizontal.  The resultant direction always has the top vector aligned with "up" and "forward".  So `currRoll` must be referring to roll as the deflection towards horizontal as you execute the gravity turn?  And then you're applying a separate 90° roll to the direction so that your ship does not try to roll during ascent?  I just wanted to confirm, since you are using a variable labeled roll where pitch is expected.

If the controls are not moving, it must think that you have a very low (or zero) steering error.  You can verify this by printing `steeringmanager:angleerror`.

Can you provide a download for the craft file you're using so that we can test it ourselves?

Scoping shouldn't be a problem in this instance, it looks like you have not adjusted the `lazyglobal` setting, so all variables should be global and won't go out of scope.  You already are setting the heading within the loop rather than in the lock expression anyways.

Are you using any mods, like FAR, that adjust the aerodynamics or physics?  What version of KSP and kOS are you using?  We may end up needing you to upload a log file, and possibly run the script with `steeringmanager:writecsvfiles` set to true so that you can upload the csv files as well.

Edited June 6, 2016 by hvacengi

[CoriW]

@hvacengi

Alright so I've done a couple things, I've added the "WAIT 0." line to the end of the until loop and I've also added "PRINT "STEER ERR: " + steeringmanager:angleerror AT (20,1)." into the loop as well. (I've also renamed "currRoll" to "currPitch" as the variable is meant to deal with pitch as you assumed, not roll. Aside from that yes I'm applying the separate 90° roll in order to prevent the rocket from rolling during ascent.

Anyways, after changing the script it now looks like this.

CLEARSCREEN.

SET desAlt TO 55000.
SET currPitch TO 0.

SET mySteer TO R(0,0,-90) + HEADING(90,90 - currPitch).

LOCK STEERING TO mySteer.
LOCK THROTTLE TO 1.0.

PRINT "Counting Down:".
FROM {LOCAL countdown IS 5.} UNTIL countdown = 0 STEP {SET countdown TO countdown - 1.} DO {
	PRINT "..." + countdown.
	WAIT 1.
}

WHEN STAGE:LIQUIDFUEL < 0.1 THEN {
	PRINT "STAGE.".
	STAGE.
	PRESERVE.
}

WAIT UNTIL SHIP:VELOCITY:SURFACE:MAG > 100.

UNTIL SHIP:APOAPSIS > 75000 {
	
	IF SHIP:ALTITUDE <= desAlt AND SHIP:ALTITUDE > (desAlt / 90) * currPitch AND currPitch < 90 {
		SET currPitch TO currPitch + 1.
		SET mySteer TO R(0,0,-90) + HEADING(90,90 - currPitch).
	}
	
	PRINT "ROLL PROGRAM: " + (90 - currPitch) + "°" AT (20,0).
	PRINT "STEER ERR: " + steeringmanager:angleerror AT (20,1).
	
	WAIT 0.
}

Upon testing the launch program again using the modified script shown above I've found that when the rocket stops obeying the "currPitch" variable, there IS steering error which means that "currPitch" is being applied to the steering correctly, but the rocket is making no attempt to correct.. I've also used Ctrl+C to abort the program when this happens, only to find that manual control shows that the rocket does have enough control authority to correct the steering error.

Here is a link to the craft file: Download

Also I'll note that yes, I do use FAR.

 

Edited June 6, 2016 by CoriW

[Amedee]

The documentation states that kOS is not compatible with SCANsat:
https://ksp-kos.github.io/KOS/structures/vessels/scienceexperiment.html?highlight=scansat

What does that mean in detail?

What I want to do:

1. Send a satellite to a planet or moon and get into orbit around it (I can do that already with kOS).
2. Activate the SCANsat part (I don't know if I can do that with kOS).
3. At regular intervals: activate a RemoteTech antenna and check for connection with the KSC (I can do that already with kOS).
4. If there is a connection, transmit any science from the SCANsat part (I don't know if I can do that with kOS).
5. Turn off the RemoteTech antenna, to save power (I can do that already with kOS).

Are my points 2 and 4 inside the scope of this incompatibility?

[hvacengi]

1 minute ago, CoriW said:

Also I'll note that yes, I do use FAR.

That would potentially explain why you had issues with just the fins. Look for the next update to FAR to possibly help with kOS performance.

I was able to launch your ship in stock KSP without kOS failing to attempt to steer.  Because of the angles of your fins it wasn't very stable (attempts to pitch cause the ship to yaw as well).  Because there is no limit to the angle of attack, that may also be contributing to the instability that I was observing.  As you climb through the atmosphere the ship becomes more stable.

[Dunbaratu]

11 minutes ago, Amedee said:

The documentation states that kOS is not compatible with SCANsat:
https://ksp-kos.github.io/KOS/structures/vessels/scienceexperiment.html?highlight=scansat

What does that mean in detail?

What I want to do:

1. Send a satellite to a planet or moon and get into orbit around it (I can do that already with kOS).
2. Activate the SCANsat part (I don't know if I can do that with kOS).
3. At regular intervals: activate a RemoteTech antenna and check for connection with the KSC (I can do that already with kOS).
4. If there is a connection, transmit any science from the SCANsat part (I don't know if I can do that with kOS).
5. Turn off the RemoteTech antenna, to save power (I can do that already with kOS).

Are my points 2 and 4 inside the scope of this incompatibility?

The thing that comment is referring to is kOS's wrapper around science modules only working with science modules that use the stock system (SCANsat does not).  What that wrapper does is this:  Normally if you use "raw" PartModule manipulation to "fire" an experiment, you can't prevent the science popup window from appearing, that the user must click on to dismiss it (it's outside of kOS's control).  But if you use kOS's wrapper around it, it will prevent the popup from appearing and do the same as if you had clicked the "keep data" button on it.

It's *that* behaviour that you cannot do with SCANsat via kOS.  You still *can* try to fire SCANsat's user right-click menu buttons in the normal raw way in kOS - you just won't have any control over the popup windows that appear as a result.

 

[Aelfhe1m]

3 hours ago, Amedee said:

The documentation states that kOS is not compatible with SCANsat:
https://ksp-kos.github.io/KOS/structures/vessels/scienceexperiment.html?highlight=scansat

What does that mean in detail?

What I want to do:

1. Send a satellite to a planet or moon and get into orbit around it (I can do that already with kOS).
2. Activate the SCANsat part (I don't know if I can do that with kOS).
3. At regular intervals: activate a RemoteTech antenna and check for connection with the KSC (I can do that already with kOS).
4. If there is a connection, transmit any science from the SCANsat part (I don't know if I can do that with kOS).
5. Turn off the RemoteTech antenna, to save power (I can do that already with kOS).

Are my points 2 and 4 inside the scope of this incompatibility?

Point 2 and 4 code sample:

Spoiler

function SCANsatEvent {
	parameter partname.
	parameter eventname.
	
	set plist to ship:partsnamed(partname).
	for p in plist {
		set m to p:getmodule("SCANsat").
		if m:hasevent(eventname)
			m:doevent(eventname).
	}
}
	
function StartSCANsatScanners {
	SCANsatEvent("SCANsat.Scanner", "start radar scan").
	SCANsatEvent("SCANsat.Scanner2", "start SAR scan").
	SCANsatEvent("SCANsat.Scanner24", "start multispectral scan").
	SCANsatEvent("SCANsat.Scanner32", "start BTDT scan").
}

function StopSCANsatScanners {
	SCANsatEvent("SCANsat.Scanner", "stop radar scan").
	SCANsatEvent("SCANsat.Scanner2", "stop SAR scan").
	SCANsatEvent("SCANsat.Scanner24", "stop multispectral scan").
	SCANsatEvent("SCANsat.Scanner32", "stop BTDT scan").
}

function SCANsatAnalyzeData {
	SCANsatEvent("SCANsat.Scanner", "analyze data").
	SCANsatEvent("SCANsat.Scanner2", "analyze data").
	SCANsatEvent("SCANsat.Scanner24", "analyze data").
	SCANsatEvent("SCANsat.Scanner32", "analyze data").
}

Clearscreen.
StartSCANsatScanners().
WAIT 10.
SCANsatAnalyzeData().

 

Note there is a distinction in SCANsat between the scan data which is continually accumulated while the scanner is running and the science data result that can be transmitted for R&D science points.