[1.3] kOS Scriptable Autopilot System v1.1.3.0

[meyerweb]

1 hour ago, hvacengi said:

When you saw that it's yawing to the left, do you mean that the controls are actively pushing the yaw control to the left?  Or do you mean that the ship slowly begins to yaw to the left and the controls do not try to pull it back to the right?  Any chance you could post a video, with and without `steeringmanager:showsteeringvectors` and `steeringmanager:showfacingvectors`turned on?  Is it always yaw, and never any other direction?

I mean I can see the needle move slightly left when I turn off SAS, and stay there.  The ship still responds to inputs, but when I stop controlling it, the slight leftward yaw is still there.  It’s always yaw, never (so far as I can see) any other direction.  I’ll try to get a video later today.

Edit: I didn’t make clear before that this happens even when no kOS program are running, and in fact when the CPU isn’t even on.  It seems to be solely a parts interaction.

Edited May 5, 2016 by meyerweb
Clarity

[Kamik423]

I am sorry. But I have bee trying all day. And I CANNOT Figure it out. I am so mad and tired.

How do I get the horizontal velocity heading of the vessel? (As scalar degrees) Nothing seems to work. And I cannot find a function for this.

 

Thanks

[Dunbaratu]

1 hour ago, Kamik423 said:

I am sorry. But I have bee trying all day. And I CANNOT Figure it out. I am so mad and tired.

How do I get the horizontal velocity heading of the vessel? (As scalar degrees) Nothing seems to work. And I cannot find a function for this.

 

Thanks

I assume you mean the compass heading (i.e. 90 degrees for east, 180 for south, etc).

If so, use the code found here:

https://github.com/KSP-KOS/KSLib/blob/master/library/lib_navball.ks

And use the function it defines called "compass_for", as in:  set deg to compass_for(ship).

 

[hvacengi]

2 hours ago, meyerweb said:

I mean I can see the needle move slightly left when I turn off SAS, and stay there.  The ship still responds to inputs, but when I stop controlling it, the slight leftward yaw is still there.  It’s always yaw, never (so far as I can see) any other direction.  I’ll try to get a video later today.

Edit: I didn’t make clear before that this happens even when no kOS program are running, and in fact when the CPU isn’t even on.  It seems to be solely a parts interaction.

I think I'm going to need to know the precise conditions where you observe this.  Is it once the linked ship reaches orbit?  Does your script release the controls during ascent and you're observing the yaw at that point?  Could you maybe post the save file with the ship already in the condition causing the error (my ascent script won't fit onto the small processor, so it's hard for me to test it in orbit myself).  I tested this by adding surface lights to my geosynchronous satellite build and didn't see any extra yaw during ascent or after releasing the controls in orbit.  But that was with 4 lights in symmetry.

[meyerweb]

3 hours ago, hvacengi said:

I think I'm going to need to know the precise conditions where you observe this.  Is it once the linked ship reaches orbit?  Does your script release the controls during ascent and you're observing the yaw at that point?  Could you maybe post the save file with the ship already in the condition causing the error (my ascent script won't fit onto the small processor, so it's hard for me to test it in orbit myself).  I tested this by adding surface lights to my geosynchronous satellite build and didn't see any extra yaw during ascent or after releasing the controls in orbit.  But that was with 4 lights in symmetry.

Posted as a gist of the save, which is pretty much four simple probes in a sandbox game and nothing else.  I named the probes around Kerbin to indicate what they have or don’t have.  If I remove SAS from Yawer, it starts, you know, yawing.  The others don’t, and may even not have SAS on right now.  I’ll be very interested to hear whether you see the same yawing when you load up the save.

[hvacengi]

3 hours ago, meyerweb said:

Posted as a gist of the save, which is pretty much four simple probes in a sandbox game and nothing else.  I named the probes around Kerbin to indicate what they have or don’t have.  If I remove SAS from Yawer, it starts, you know, yawing.  The others don’t, and may even not have SAS on right now.  I’ll be very interested to hear whether you see the same yawing when you load up the save.

Found your problem:

			CTRLSTATE
			{
				pitch = -2.181771E-06
				yaw = -6.425296E-06
				roll = -9.487868E-07
				trimPitch = 0
				trimYaw = -0.036
				trimRoll = 0
				mainThrottle = 0
			}

Printing `ship:control:pilotyaw` prints 0.035999994502792.  The issue isn't the mod, just reset your yaw trim (via KSP controls, not kOS's trim).  Toggling the torque wheel off stopped the spinning, so I knew it had to be something affecting the controls.

Edited May 6, 2016 by hvacengi

[Warp11]

Is there a way to switch off cooked control for just one axis? For example I want to raw control roll while cooked is holding pitch and yaw. What I did so far was set steeringmanager:rolltorquefactor to 99999999999. But that's not a very elegant solution and it seems to be overriding my raw control for roll (it used to work though). Thx

[Alchemist]

Ir raw control is not 0, it overrides cooked control on that axis. (But you may want to have it at something like 0.0001 when the control formula returns 0)

[Warp11]

40 minutes ago, Alchemist said:

Ir raw control is not 0, it overrides cooked control on that axis. (But you may want to have it at something like 0.0001 when the control formula returns 0)

Yeah its doing that when I try it outside of a script but inside the script it doesn't work. Ship:control:roll is -1 even after I abort the script and cooked unlocks but the control indicator is not doing anything. It used to work I don't know whats wrong. My relevant part of the script is here:
 

set rtref to time:seconds.
set stm to steeringmanager.
until RM = 0 {
	if RM = 4 { // roll
		set yawthrottle to 0.
		set pitchthrottle to 0.
		set stm:rolltorquefactor to 99999999999.
		set stm:pitchts to (5/max(0.000001,abs(stm:pitcherror))) + 0.5.  //scale settling time by error to save fuel
		set stm:yawts to (5/max(0.000001,abs(stm:yawerror))) + 0.5.
		lock steering to tatt.	//tatt being the target attitude as a rotation
		set rt to tatt:roll.
		set rc to ship:facing:roll.
		set rollerr to rt - rc.
		if rollerr < -180 set rollerr to rollerr + 360.
		if rollerr >  180 set rollerr to rollerr - 360.
		
		set rollrate to Vdot(ship:angularvel,ship:facing:forevector)*constant:radtodeg.
		set rstopang to constant:radtodeg * (rollrate*constant:degtorad)^2 / (2*rollangacc).
		
		if subrm4 = 4.1 and abs(rollerr) > 2 {
			print "Status: Initiating Roll       " at (2,13).
			set rollthrottle to -abs(rollerr)/rollerr. //1 or -1
			set rtacc to time:seconds - rtref.
			set rollangacc to ship:angularvel:mag/max(rtacc,0.000001).
			if abs(rollrate) > trollrate or abs(rollerr) -3 < rstopang {
				set rollthrottle to 0.
				set subrm4 to 4.2.
			}
		}
	}
	if rollthrottle=0 set ship:control:roll to 0.0001.
	else set ship:control:roll to rollthrottle.
	
	print "Roll:    " + round(rollthrottle,3) + "  " at (2,17).
	
	print "Rollerr: " + round(rollerr,2) + "  " at (2,23).
	print "Rstopang:" + round(rstopang,2) + "  " at (2,24).
	print "Rollrate:" + round(rollrate,3) + "  " at (2,25).
	
}

Thank you for your help.

EDIT: I just tested again this time with the rolltorquefactor set to 1 and it seems the cooked steering is overriding the raw here. The control indicator follows cooked while ship:control:roll = -1.

EDIT: This program by itself seems to run fine but integrated into my whole rotation program it doesn't work. I'll have to dig into that.

 

Edited May 6, 2016 by Warp11

[Warp11]

I'm at a loss. Ship:control:roll is -1, its printing that on the screen but the controls still follow the cooked steering. Does anyone know what could be causing this?

[meyerweb]

7 hours ago, hvacengi said:

Found your problem:

			CTRLSTATE
			{
				pitch = -2.181771E-06
				yaw = -6.425296E-06
				roll = -9.487868E-07
				trimPitch = 0
				trimYaw = -0.036
				trimRoll = 0
				mainThrottle = 0
			}

Printing `ship:control:pilotyaw` prints 0.035999994502792.  The issue isn't the mod, just reset your yaw trim (via KSP controls, not kOS's trim).  Toggling the torque wheel off stopped the spinning, so I knew it had to be something affecting the controls.

How do I do that?  Seriously, I have no idea how one uses KSP’s controls to permanently change or reset the yaw trim.

Also, do you have any idea how it might have gotten into this state?  I have another (very, very, very different) craft in a different save with the same yaw problem, so any ideas as to how this happened will help me avoid doing it again in the future.

[hvacengi]

3 hours ago, Warp11 said:

Is there a way to switch off cooked control for just one axis? For example I want to raw control roll while cooked is holding pitch and yaw. What I did so far was set steeringmanager:rolltorquefactor to 99999999999. But that's not a very elegant solution and it seems to be overriding my raw control for roll (it used to work though). Thx

1 hour ago, Warp11 said:

I'm at a loss. Ship:control:roll is -1, its printing that on the screen but the controls still follow the cooked steering. Does anyone know what could be causing this?

Mixing the use of raw and cooked steering like this is not supported (and honestly, should have given you an error).  If you are able to make it work in an instance, it probably is related to the order in which you set up the controls.  Currently, every time that you call `lock steering` it subscribes to the autopilot events, and the fist time you set a suffix on `ship:control` it will bind to the events.  So the two will be evaluated in the order you set them up (this will be changing in a future release as I am updating how steering is processed).  Another related quirk is that every time you call `lock steering` it will re-assert itself as the last thing to update (the act of locking will unbind the steering and the immediately re-bind it).  So if you set a value on `ship:control` in the parent script, and then `lock steering` in this script steering will always override the setting.  If you want to try and re-assert `ship:control` in the order, calling `set ship:control:neutralize to true` will unbind it, so that the next time you set any of the suffixes it will be moved to "last in line".  Just make sure that you don't directly call `lock steering` afterwards.

Which brings me to a 2nd point.  You really should not call `lock steering` repeatedly in a loop like your code shows.  This forces an unbind/bind every time through the loop (which is expensive), and it resets the steering manager's integral components (which is actually broken in the release version, but will be a big deal in the next release).  A far better solution (especially in your use case) would be to lock the steering to `tatt` before the loop, because it looks like tatt is being updated externally (possibly using a lock or within a when/then block.  The whole purpose of using a `lock` object for steering is because locks automatically update (in normal code you don't want to repeatedly call `lock` either unless the code being evaluated is changed).

24 minutes ago, meyerweb said:

How do I do that?  Seriously, I have no idea how one uses KSP’s controls to permanently change or reset the yaw trim.

Also, do you have any idea how it might have gotten into this state?  I have another (very, very, very different) craft in a different save with the same yaw problem, so any ideas as to how this happened will help me avoid doing it again in the future.

Trim is set by pressing the modifier key (alt on windows) and one of the translation controls.  You can reset it using the modifier key and "x".  This is not a control listed in the KSP settings, but you can find it on the KSP wiki.  I verified that on the save file provided [Alt]+[X] stopped the errant yaw.

[Warp11]

@hvacengi Thank you for your detailed response. I don't have time to try it today anymore but I'll do so tomorrow. That really clears things up for me.

[meyerweb]

1 hour ago, hvacengi said:

Trim is set by pressing the modifier key (alt on windows) and one of the translation controls.  You can reset it using the modifier key and "x".  This is not a control listed in the KSP settings, but you can find it on the KSP wiki.  I verified that on the save file provided [Alt]+[X] stopped the errant yaw.

…holy carp.  I had no idea.  That’s how I ended up with a yaw trim: I use the alt-A shortcut to open AnyRes, not realizing it would affect yaw.  I suspect the creator of AnyRes may also not have realized that.  alt-X absolutely fixed it.  Thanks, @hvacengi!  Very much appreciated.

[Drew Kerman]

4 hours ago, meyerweb said:

…holy carp.  I had no idea.  That’s how I ended up with a yaw trim: I use the alt-A shortcut to open AnyRes, not realizing it would affect yaw.  I suspect the creator of AnyRes may also not have realized that.  alt-X absolutely fixed it.  Thanks,

if you haven't already, you might want to adjust your game's key settings until AnyRes has its own way to change keys

[angrybold]

i happened upon a problem i cannot resolve on my own.

i run my node execution script inside another script but it will end up breaking the script when trying to reove nextnode, saying that there is no nodes present.

however, there is a node present, which is beeing removed as intended.

it just fails after that.

what am i doing wrong?

[Alchemist]

Did you leave steering locked to something dependent on the node?

[angrybold]

love you alchemist

excrements like that should be more aparent for me :/

welp now my rendezvous script works. that was a pain for my limited skills.

[Lookerksy]

Does it work in 1.1.2 ? Thanks.

[hvacengi]

1 hour ago, Lookerksy said:

Does it work in 1.1.2 ? Thanks.

 

On 5/5/2016 at 10:47 PM, hvacengi said:

On 5/4/2016 at 4:36 PM, Beechnutk Jr. said:

I am sorry if this has already been asked, but I did not see it in the replies. Any plans for 1.1.2 compatibility? This is essential to my modpack, since I am using remotetech. Any news would be welcome. 

 

Thanks!!

Everything except setting the target works with the existing release (compared to for KSP 1.1.0) (as far as we're aware).  We have a large number of pending revisions, and want to get them integrated before our next release.  Hopefully that will be soon, but it's a lot to review and various devs have been short on time recently.

We will be having another release which is explicitly compatible.  I would like to have it sooner rather than later, but it depends on timing of reviews.

Edited May 9, 2016 by hvacengi

[Lookerksy]

3 hours ago, hvacengi said:

 

We will be having another release which is explicitly compatible.  I would like to have it sooner rather than later, but it depends on timing of reviews.

Thanks for your quick reply. I'm very dependant on kOS. Hope new version will be released ASAP.

[Horman]

I just want to say thanks you to the devs for their great support here!
You are doing an amaizing job!

[Viggen]

Hello! It seems to me that kOS have some problem with new Realism Overhaul release in 1.1.2. Parts containing kOS storages starting rapidly increase their mass when placed in VAB or SPH and continuing doing so on launchpads.. I don't know on which end problem lies, so I'm just writing in both threads, that it worth to be looked at.

[Dunbaratu]

3 hours ago, Viggen said:

Hello! It seems to me that kOS have some problem with new Realism Overhaul release in 1.1.2. Parts containing kOS storages starting rapidly increase their mass when placed in VAB or SPH and continuing doing so on launchpads.. I don't know on which end problem lies, so I'm just writing in both threads, that it worth to be looked at.

For now, because other people have reported problems with things other than kOS parts having mass mysteriously grow bigger and bigger in the VAB when they have RO installed, I'm inclined to assume it's RO, not kOS. 

[Kookas]

For me, LOCK THROTTLE doesn't work. Nothing happens when I do e.g. LOCK THROTTLE TO 1. The example script doesn't work either.