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

[kcs123]

16 minutes ago, danielboro said:

ill add my observation

in 1.6.1 after updating KOS did not work
went back  one step and KOS is working

Are you using KAS or Wind tunnel mod ? Fix for those are created, but not merged and published yet:

 

[Dunbaratu]

1 hour ago, danielboro said:

ill add my observation

in 1.6.1 after updating KOS did not work
went back  one step and KOS is working

That really needs more description than that.  What does "did not work" actually mean?  As in, what did you try doing and what happened instead of what was supposed to happen?

[Dunbaratu]

1 hour ago, kcs123 said:

Are you using KAS or Wind tunnel mod ? Fix for those are created, but not merged and published yet:

In the case of Wind Tunnel, Wind Tunnel has a new version out that fixed it.

(The problem can be fixed on either end because its caused by two problems that have to both exist for the bug to occur:

Problem 1: The other mod has to have a Plugin DLL that is failing to load because of some kind of incompatibility with KSP or Unity or Mono version.

Problem 2: The kOS mod performs a reflection walk of all classes that didn't protect itself against the exceptions that such a walk will throw when any other DLL didn't load right.  I didn't know Microsoft designed their reflection system that way.  It's weird to me and I didn't notice the "fine print" in the .net documentation that mentioned it.)

If either Problem 1 or Problem 2 is fixed, the bug goes away.  I have Problem 2 fixed in develop but not released yet.  The reason I didn't hurry to release is that I knew the other mods would have to fix their "Problem 1"'s anyway for their own mods to work, so most of the onus was on them.

Wind Tunnel fixed Problem 1 with a new release on their end explicitly for fixing this problem.
KAS has a brand new release for KSP 1.7 out, but I haven't had a chance to test it and see if it fixed their "Problem 1" or not.

[Dunbaratu]

New Release.  Look for it at the usual places.

kOS v1.1.8.0 - this is mostly just for compatibility and to make it official that kOS supports KSP 1.7 (rather than it being the case that it just happens to work by happy accident.)

 

Along the way there were one or two bug fixes and documenation
cleanups.

BREAKING CHANGES

• Not that we know of, unless you were unaware that some of
  the bugs fixed were in fact bugs and had written a script
  to expect that behaviour as normal. (Read the bug fixes
  below to be sure.)

NEW FEATURES

• Support of multiple-at-the-same-time engines that exist in
  some mods (but not in stock, as far as we can tell). Stock
  contains single engines in a part, and multi-mode engines
  in a part (where only one of the engines in the part is
  active at a time, i.e. wet/dry mode engines or jet/rocket
  mode engines). But some mods contain parts that have more
  than one engine in them that are selected at the same time,
  rather than toggle-switched like the stock multi-mode engines.
  One example is the RD-108 engine that the RealEngines mod
  provides. Its main "straight" engines are one Engine Module,
  and its smaller "gimbal" engines around the edge are a second
  Engine Module. Both modules are active at once and need their
  information aggregated to work with kOS's "an engine part is
  just one module" system. This PR does so.
  pull request
  Special thanks to first time contributer RCrockford for doing
  all the legwork on this.

BUG FIXES

• The behaviour of LIST ENGINES in regards to multi-mode engines
  was restored to what it was supposed to have been. Becuase of a
  small change KSP made, it's been wrong since KSP 1.5, apparently.
  Prior to KSP 1.5 it worked correctly by giving a list that contains
  one entry in the LIST ENGINES per engine. But since then it has been
  returning 3 duplicate instances in the list per each multi-mode engine.
  This release fixes it, and the previous correct behavior is restored
  (just returning one, not three).
  The problem was discovered during regression testing of
  the pull request,
  so the fix is inside that same pull request.
• kOS could be rendered completely inert and broken if other mods not
  under kOS's control had broken DLL files. Specifically, kOS would
  abort partway through initializing itself if any other DLL file in the
  entire KSP game had failed to load during the KSP loading screen. kOS
  has a "reflection" walk through all the classes that hadn't accounted
  for the fact that .net apparently keeps a null stub of a class in memory
  after a class fails to load, rather than it just not existing at all
  like one would expect.
  pull request
  (This was discovered with KSP 1.7 because KSP 1.7 broke some other
  mod's DLLs making them not load, but the problem was actually there
  all along waiting for some DLL file to trigger it.)
• Reworking the position of the Connectivity Manager Dialog box.
  Our exploratory reverse-engineering of just what the undocumented
  arguments to KSP's MultiOptionDialog mean, which was used to move the
  box to fix issue 2456
  were still wrong. They didn't do exactly what we thought they did.
  (The misinterpretation became relevant when the player has UI scaling
  set higher than 100% and that pushed the dialog box off screen.)
  Thanks to contributor madman2003 for doing more reverse-engineering
  on this and submitting the fix.
  pull request
• Fix to bug where kOS scripts could no longer SET TARGET to a
  Celestial Body and could only set targets to vessels or parts.
  This bug was introduced in the previous release of kOS by a
  hamfisted typing error while fixing the fact that Body wasn't
  serializable. It was an error that unfortunately didn't result
  in any noticable problem when compiling or testing, as it
  only removed the Body's declaration that "I am the kind of class
  that knows how to be a target" and it affected nothing else.
  pull request
• Several small documentation edits:
  pull request,
  pull request,
  pull request
• Trying to toggle the panels value on or off would result
  in infinite log spam if the ship contained a fixed undeployable
  solar panel like the OX-STAT. kOS was watching for the existence
  of ModuleDeployableSolarPanel to see if the part could be deployed
  or not, but apparently at some point KSP started defining all
  solar panels as having ModuleDeployableSolarPanel, even if they're
  not actually deployable. Now kOS doesn't treat the panel as
  deployable unless it also has its animation property defined in
  addition to claiming to be a ModuleDeployableSolarPanel.
  pull request

[danielboro]

20 hours ago, Steven Mading said:

That really needs more description than that.  What does "did not work" actually mean?  As in, what did you try doing and what happened instead of what was supposed to happen?

this was resolved long time ago as part of the wind tunel/KAS problem

edit: i wrote that before the 16/ April
i have no idea way it only got posted yesterday 

@kcs123

Edited May 2, 2019 by danielboro

[kcs123]

8 hours ago, danielboro said:

this was resolved long time ago as part of the wind tunel/KAS problem

edit: i wrote that before the 16/ April
i have no idea way it only got posted yesterday

No problem, forums can be weird sometimes. I'm glad that you have sorted it out and that everything works as intended for you.

[RizzoTheRat]

Hi folks.  Are there any issues with RemoteTech connectivity and KOS?

I have relay satellites orbiting Kerbin and Minmus, all of which are showing Homeconnection:Isconnected=True, as is my station orbiting Minmus, however my lander, currently in a low Minmus orbit, shows as being connected as far as RemoteTech is concerned (antenna shows Status:connected and I'm getting the line on the map view), but it KOS reckons HomeConnection:IsConnected=False

The station has a 5Mm Communotron 32, while the lander only has a 1.5Mm Communotron 16-S, but the KommSats are orbiting about 445km, so should be well within range.

[Dunbaratu]

51 minutes ago, RizzoTheRat said:

Hi folks.  Are there any issues with RemoteTech connectivity and KOS?

I have relay satellites orbiting Kerbin and Minmus, all of which are showing Homeconnection:Isconnected=True, as is my station orbiting Minmus, however my lander, currently in a low Minmus orbit, shows as being connected as far as RemoteTech is concerned (antenna shows Status:connected and I'm getting the line on the map view), but it KOS reckons HomeConnection:IsConnected=False

The station has a 5Mm Communotron 32, while the lander only has a 1.5Mm Communotron 16-S, but the KommSats are orbiting about 445km, so should be well within range.

1- Is your ConnectivityManager set to RemoteTechConnectivityManager?

2 - Does your Vessel have a probe core with a Module SPU on it?  The Remote Tech API will not show the connection to home if it does not (regardless of what it shows on the UI. It's annoying but that's how it works.)

3 - Which version of KSP and which version of kOS is it?  There were some fixed bugs but I don't know if you have them yet.

[RizzoTheRat]

It was on RemoteTechConnectivityManager, I've switched it to PermitAllConnectivityManager for now to bypass the problem.

I haven't got a probe core on the ship, just a Mk2 lander can with a couple of of crew.  What do you mean by Module SPU?  Sounds like that could be issue as the Station, which does work correctly, has an OKTO.  If that's the case it's an easy workaround to always make sure my ships have a probe core.

KSP 1.6.1 and KOS 1.1.6.2

 

 

[Dunbaratu]

46 minutes ago, RizzoTheRat said:

I haven't got a probe core on the ship,

That is why.  We can't fix this on our end.  It's Remote Tech.  Their API call that we use refuses to see connections if the vessel is purely a manned-only capsule without a probe core.  Even though, as you say, they CAN detect the connection in their own UI, they don't expose that connection through their API call unless the vessel has a probe core on it.

When using RT, make sure your vessels always have a probe core even if they are manned.

 

[RizzoTheRat]

Thanks,  easy fix for future ships.

[Lookerksy]

Hi, author.
I noticed that the IR-Next has been updated to InfernalRobotics_v3.0.0_beta4p1.
And the Addons:IR of latest version kOS doesn't support it.
Will you plan to support new IR-Next in the next version? Thanks.

[Flibble]

Is anyone else using compiled .ksm files? I have an issue where a script that works fine as text runs really slowly when compiled. I've opened an issue on GitHub, but thought I'd check here too.

[TranceaddicT]

So, I'm taking my first dive on kOS thanks to @SpinkAkron and his wonderful YouTube series.

First thing, I'm wondering is if there is a syntax template lurking about for sublime text?

 

Nevermind, there's this:

https://github.com/KSP-KOS/EditorTools/tree/develop/SublimeText3

Edited May 13, 2019 by TranceaddicT

[kcs123]

Found some small compatibility issue between kOS and RealChute mod. It is being present for a while, but I forgot to mention it before (several KSP and kOS versions ago).

Reproducing steps and description:

1. Have some craft in orbit with only 2 stages left. Last stage contains decoupler and RealChute. Current stage have some engine engaged with some fuel left.
2. Open terminal and type some command in it. For example, I want to run my script with command; "run maneuver."
3. What is expected is to kOS run that script, but as side effect RealChute also "arm" parachutes to deploy at certain altitude or preassure.
4. Note that proper KSP stage is not executed, decoupling of last stage didn't happened, only RealChutes become "armed"

I'm not sure is it issue on RealChute mode side or on kOS side. It was not something critical either, but can be annoying sometimes if I didn't noticed and disarmed chutes on time.

[Drew Kerman]

Looking for insight on the cooked steering after seeing a behavior in my rocket I'm not sure how best to correct. First, here's the rocket:

It uses control surfaces, no engine gimbal, which are aligned with the capsule so the top and bottom fins seen in the image above are mainly yaw while the left/right fins (left fin visible above) handle pitch and roll.

Guidance is taken from CheersKevin's youtube video using a quadratic fit function. Specifically, this is the ascent profile used in my latest launch:

Which results in a pitch calculation of

lock pitch to 2.51091E-8 * ship:altitude^2 - 0.00206121 * ship:altitude + 90.2484.

which is assigned to the cooked steering via

lock steering to heading(hdgHold,pitch).

In this instance my hdgHold is 53°. The improper behavior I've seen on all my ascents to varying degrees has been some relatively extreme pitching moments off the desired profile:

Click for the stupid-large resolution that makes the steering errors below 10km more apparent.

So the "Actual" data is from my kOS logger spitting out the pitch of the rocket every second, along with the altitude and other information. In Excel I've used the altitude and the quadratic fit equation to generate the degree of pitch the rocket should be reaching at that point, which is the "Fit" plot.

The behavior seems to be the rocket pitches over too fast, reaches a point where it's like "whoops! Where am I going?" and then over-corrects. But then shortly after it starts to drift off in the opposite direction, brings itself more gradually back and finally matches up to the fit plot before beginning to deviate again passing through 30km - but that at least is understandable and expected as the air thins and control authority weakens.

In both cases where the actual pitch deviates from the fit plot the rocket is only at ~50%  or less control saturation, so it's not simply a matter of the rocket being unable to maintain the proper pitch angle.

The only other factor in the steering is my heading, and when I normalize the values for pitch and heading I get a strong correlation - which makes sense given the same controls are used for roll and pitch:

By 60s after launch the rocket is finally heading 53° and does not deviate a fraction from it, which is the red line going flat, and is also at the altitude at which the previous plot above this one converges and follows the pitch profile perfectly until the air thins out.

I already think I can make things better by pitching right off the pad a teensy bit more before I switch into the guidance program because there's a bit of gimbal lock going on right at the start of my ascent where the pitch readouts in the game itself start at 45° (the way the rocket is facing on the pad) for the first 2-3s before jumping straight to 20° once pitch drops to below 89.8° - that's the big correction seen early on in the plot above.

If anyone has additional suggestions I would appreciate any input. Thanks!

Edited May 16, 2019 by Drew Kerman

[FloppyRocket]

6 hours ago, Drew Kerman said:

Looking for insight on the cooked steering after seeing a behavior in my rocket I'm not sure how best to correct. First, here's the rocket:

ppreciate any input. Thanks!

Nice set of data. Do you also have any velocity data you can plot that goes along with pitch and altitude?

Since you're steering using fins, airspeed is probably significantly important.

[Flibble]

I'm no expert on PID controllers, but first thoughts are that your control surfaces lack sufficient authority early in flight (due to low airspeed most likely), this means that when it's trying to both yaw and pitch it can't make the manoeuvre it would like so the integral error term builds up. This then causes an overshoot as authority increases before settling down as the system damps down.

Options to fix are either fix heading before pitching, somehow gain more authority (engine gimbals maybe), or reduce the integral term, though this last option may cause instability further into the flight.

EDIT: noticed you said control surfaces are not saturated, which means maybe not this. You could try reducing the integral term and boosting derivative to give more damping to the system to reduce overshoot maybe?

Edited May 17, 2019 by Flibble

[Drew Kerman]

4 hours ago, FloppyRocket said:

Nice set of data. Do you also have any velocity data you can plot that goes along with pitch and altitude?

Since you're steering using fins, airspeed is probably significantly important.

I didn't consider this a factor since the control surfaces were not being overworked at all at these points in the flight. When it came off the pad the gimbal lock dropped its heading from 45° to 20° and it was able to snap roll over back to 43° in under two seconds, but then it was also starting to pitch over and took its time getting to 53°

3 hours ago, Flibble said:

You could try reducing the integral term and boosting derivative to give more damping to the system to reduce overshoot maybe? 

thanks, I will keep that in mind. My first fix attempt tho will be as you also suggest and as I surmised - get a more stable heading off the pad

[kcs123]

4 hours ago, Drew Kerman said:

thanks, I will keep that in mind. My first fix attempt tho will be as you also suggest and as I surmised - get a more stable heading off the pad

Yep, it is always good idea to start steering only when your craft gain some velocity, usualy above 120 m/s (depending on craft), but should also be carefull to s steer gently while below 10km and with velocity close to mach 1. Based on empirical results in KSP, most critical regime is from 0.8 mach up to 1.2 mach when you are below 10 km. After that steering is much more forgiving.

Btw. thanks for sharing that video and examples. That gave me idea to attempt create cubic spline interpolation function for kOS. Alghorithm is shown on linked page, just a matter to code it in kOS. Someone have already made kOS function for linear interpolation somewhere (can't recall where, sorry), but cubic spline interpolation is more precise.

Somehow I often get traped in more investigation and re-learn forgoten skills as well as learning something new when I attempt to just play a game for a while :).

Edit:

Even better page with interpolation alghoritm.

Edited May 17, 2019 by kcs123

[Flibble]

Depending on your source data you can get odd effects with cubic interpolation if you don't have tangent data. It's worth looking at monotonic interpolation if you just have data points.

[kcs123]

3 hours ago, Flibble said:

Depending on your source data you can get odd effects with cubic interpolation if you don't have tangent data. It's worth looking at monotonic interpolation if you just have data points.

Might look into that as well, thanks for mention it.

[TranceaddicT]

11 hours ago, kcs123 said:

Someone have already made kOS function for linear interpolation somewhere (can't recall where, sorry), but cubic spline interpolation is more precise.

Might you be thinking of the KSLib repository, here:

https://github.com/KSP-KOS/KSLib

[kcs123]

8 hours ago, TranceaddicT said:

Might you be thinking of the KSLib repository, here:

https://github.com/KSP-KOS/KSLib

Nope, wasn't found in that library, must be elsewhere, but it does not matter. I have created monotone cubic interpolation function for usage in kOS.
Wasn't tested extensively, altitude/piching points may require some tweaking too, but general functionality of spline interpolation works as intented.
When I started to test, my previously working rocket started to explode on staging. I think it is KJR next culprit, since it is only mod updated since yesterday.
But, that is different kind of animal that I need to tacle down. kOS script prepared to be used as library is under spoiler:

Spoiler

// This file is distributed under the terms of the MIT license

// Using Monotone cubic interpolation to calculate Spline:
// https://en.wikipedia.org/wiki/Monotone_cubic_interpolation
// Special thanks to CheersKevin and Drew Kerman for idea
// ported from javascript code to kOS by kcs123

@lazyglobal off.

// Arrays for Altitude vs Pitch points
// AltPoint - must be sorted in ascending order, last point is Apoapsis
declare global AltPoint is   list( 0,2000,3000,4000,5000,6000,8000,16000,22000,44000,60000,70000,120000). 
declare global PitchPoint is list(90,  87,  77,  74,  68,  65,  60,   55,   45,   25,   15,   10,0). // Ys - Pitch at AltPoint

// For consecutive differences and slopes results
declare global dXs to list().
declare global dYs to list().
declare global ms to list().
declare global cls to list().
declare global c2s to list().
declare global c3s to list().

declare global InterpOut to "".

declare function PopulateInterpolant {
	set InterpOut to "".
	// Preparing variables that need to be calculated only once.
	// reseting old values if function is called more than once from main script
	dXs:clear().
	dYs:clear().
	ms:clear().
	cls:clear().
	c2s:clear().
	c3s:clear().
	
	// Sanity check for list length
	if (AltPoint:length <> PitchPoint:length) {
		set InterpOut to "Error: Need eaqual number of altitude and pitch points".
		return.
	}.
	if (AltPoint:length < 3) {
		set InterpOut to "Error: Need at least 3 points for sane interpolation".
		return.
	}.

	// Get consecutive differences and slopes 
	from{local i is 0.}until (i = AltPoint:length - 1) step{set i to i+1.} do {
		local dX to AltPoint[i+1] - AltPoint[i].
		local dY to PitchPoint[i + 1] - PitchPoint[i].
		
		dXs:add(dX).
		dYs:add(dY).
		// sanity check to prevent divide by zero, but may produce interpolation errors
		if dX = 0 {
			ms:add(0).
		} else {
			ms:add(dY/dX).
		}.
		
		set InterpOut to "Calculating dX: #"+i.
		}.
	
	// Get degree-1 coefficients
	set cls to list(ms[0]).
	from{local i is 0.}until (i = dXs:length - 1) step{set i to i+1.} do {
		local m to ms[i].
		local mNext to ms[i + 1].
		
		if (m*mNext <= 0) {
			cls:add(0).
		} else {
			local dx_ to dxs[i].
			local dxNext to dxs[i + 1].
			local common to dx_ + dxNext.
			cls:add(3*common/((common + dxNext)/m + (common + dx_)/mNext)).
		}.
		set InterpOut to "Calculating degree-1 coeff: #"+i.		
	}.
	
	// Get degree-2 and degree-3 coefficients
	from{local i is 0.}until (i = cls:length - 1) step{set i to i+1.} do {
		local c1 to cls[i].
		local m_ to ms[i].
		local invDx to 1/dxs[i].
		local common_ to c1 + cls[i + 1] - m_ - m_.
		c2s:add((m_ - c1 - common_)*invDx).
		c3s:add(common_*invDx*invDx).
		
		set InterpOut to "Calculating degree-2 and 3 coeff: #"+i.
	}.
	
	set InterpOut to "Interpolant calculated".	
}.

function CalculatePitch {
	parameter CurrentAltitude.
	
	local Pitching to 0.
	local low to 0.
	local mid to 0.
	local high to 0.
	local xHere to 0.
	local diff to 0.
	local diffSq to 0.
	
	// The rightmost point in the dataset should give an exact result
	local i to AltPoint:length - 1.
	if (CurrentAltitude = AltPoint[i]) {
		set Pitching to PitchPoint[i].
		set InterpOut to "Pitching last point  ".
	} else {
		
		// Search for the interval CurrentAltitude is in, returning the corresponding y if CurrentAltitude is one of the original Altitude points
		set low to 0.
		set mid to c3s:length - 1.
		set high to c3s:length - 1.
		
		until not (low <= high) {
			set mid to floor(0.5*(low + high)).
			set xHere to AltPoint[mid].
			if (xHere < CurrentAltitude) {
				set low to mid + 1.
			} else {
				if (xHere >CurrentAltitude) {
					set high to mid - 1.
				} else {
					set InterpOut to "Pitching mid point    ".
					return PitchPoint[mid].
				}.
			}.
		}.
		
		set i to max(0, high).
		
		// Interpolate
		set diff to CurrentAltitude - AltPoint[i].
		set diffSq to diff*diff.
		set Pitching to PitchPoint[i] + cls[i]*diff + c2s[i]*diffSq + c3s[i]*diff*diffSq.
		set InterpOut to "Pitching Interpolated ".
	}.
	
	return Pitching.
}.

 

Example of usage from main script:

parameter MyHeading is 90. // initial heading for orbit - influence starting inclination
parameter MyApoapsis is 120000. // Desired APOAPSIS of orbit
clearscreen.
// load the libraries I'm using:
runoncepath("lib_navball").
runoncepath("interpolation_lib").

// you can override default AltPoint and PitchPoint list set in interpolation_lib
// first you need to clear list and then set new points for both arrays
  
// last point on interpolation graph must be always Apoapsis
set AltPoint[AltPoint:length-1] to MyApoapsis.
PopulateInterpolant(). // first call on startup - you need to execute it each time you change Apoapsis

print InterpOut. // you can use this value to check for errors and track what is interpolation doing

function AltitudePitch{
	local Pitching is 90.
	if (SHIP:ALTITUDE > 1000) or (SHIP:AIRSPEED > 100){
		set Pitching to round(CalculatePitch(round(SHIP:ALTITUDE)),2).
	}.
	DynamicDisplay("Turning to: "+Pitching+"      ").
	return Pitching.
}.

wait until SHIP:MAXTHRUST > 0. // waiting idle until staged once for launch
// program will not continue down until staged
SAS off.
DynamicDisplay("Launch started").

// Initial throttle and heading
SET SHIP:CONTROL:PILOTMAINTHROTTLE TO 1.
lock STEERING to HEADING(MyHeading,90). // works better than UP direction as UP tend to rotate

wait until SHIP:AIRSPEED > 70. // no stearing until proper velocity gained
set myPitch to AltitudePitch(). // first input from Pitching curve function
// Lock is needed only once, outside loop, steering will be changed whenever myPitch changes
lock STEERING to HEADING(MyHeading, myPitch).

until (ship:APOAPSIS >= MyApoapsis) {
	set myPitch to AltitudePitch().
	wait 1.
}.

I have maybe over engineered library script and wrote comments for easier tracking if I have made mistake somewhere. For that reason, file is bigger than need to be. It is clearly disadvantage.
However, you can tune altitude/pitch graph points that suit well for your crafts and wanted ascent path in easy way. You would not need to use external tools to calculate constants for pitch function.

Let me know if you have tested it and how it is working for you. Also, feel free to upload it to kOS github library, if you find that have some merit. I still don't have account on github and don't plan to create one yet.

[Drew Kerman]

3 hours ago, kcs123 said:

Let me know if you have tested it and how it is working for you

Will likely use this as "new guidance software" for my Progeny Mk7 rockets that I plan on flying over the summer. Will def report back with analysis if I do

Edited May 18, 2019 by Drew Kerman