[1.3] kOS Scriptable Autopilot System v1.1.3.0

[erendrake]

[h=2]Steering More Much Betterer[/h][h=3]Changes[/h]

• Changed default MaxStoppingTime to 2 seconds ( was 1 )
  

[h=3]BUG FIXES[/h]

• Fixed a issue where the effect of the Kd parameter of PIDLoop was having a reversed effect #1229
  
• Fixes an issue where NO_FLOW resources ( eg SolidFuel ) were not reporting correctly #1231
  

[tewpie]

In every experiment I conducted, the old cooked steering was an epic failure when using either control surfaces, or gimbals as the primary source of torque. I'm happy that these values worked well for you in all instances, but that was by no means the norm.

I'll take your word for it, I guess. My experience was very much to the contrary.

Now:

The new system is not just a PID loop with some tuned constants. The first modification I made was to add a calculation of engine gimbal torque, allowing the calculation to remain accurate when the available torque from the engines dwarfed that from reaction wheels and RCS (for example a gimbaled launcher, with a satellite on top). Next, I worked with another contributor on an accurate model for calculating required/target torque to achieve a desired angular velocity. After that, I implemented a total of 6 PID loops to calculate the target angular velocity and torque about 3 different axes. Finally, I wrote an algorithm that analysis the observed change in angular velocity, and automatically adjusts the "available torque" based on a running average....

Yes, I got the gist of that from reading your code. You're trying to do two (possibly conflicting) things here: 1) Offer a turnkey steering solution 2) Offer a semi-tunable steering method that's more user friendly than a custom-made PID loop. My contention is that

1) the turnkey solution is worse than the original solution *in terms of being turnkey*. While it can probably cover more cases *with tuning*, it performs worse "out of the box" (in my experience).

2) the semi-tunable solution is less user friendly than just "rolling your own". PID loops are very well understood, and a user sophisticated enough to write a KOS script in the first place should be able to write one. The new cooked steering adds a layer of abstraction on top which makes tuning extremely difficult (tuning PID parameters exposed by SteeringManager does NOT produce the results one would expect from turning a standard PID loop). Users are forced to learn how to tune "KOS Steering", which is much more esoteric and frankly useless than learning how to tune a PID loop. While there could eventually be a library of useful tuning parameters, any changes to your algorithm (I see some TODOs) effectively breaks the library.

If we had chosen to maintain two tracks of steering, the answer to any issue with legacy steering would be "use the new steering".

"Use the new steering" is a perfectly fine answer. Why not encapsulate and deprecate the old behavior without removing it? Actually, if I submitted a patch to reintroduce this as a deprecated feature that's enabled by a flag, would the dev team accept it?

All of this being said, we do want to get feedback on default tuning. We are already preparing to adjust a couple of default parameters in the next patch. There has even been discussion of adding some "recommended" tuning scripts to KSLib for different shapes/classes of ships. The easiest way for us to give the users a good default performance is to get feedback on what values work most often for most users.

That's great, but why not keep the old code path until there is a robust library and documentation on the new stuff?

I should be setting up a stream tomorrow afternoon to go through the new features in 0.18.0 and help with issue as well as real time feedback/discussion. I'm also planning on writing a tuning FAQ of sorts, and doing a video to walk through some of the behaviors.

Cool!

[tewpie]

Well I went ahead and encapsulated the old steering logic and added a bound variable flag to enable/disable it. Took about 1 hour.

If the dev team is interested in this, let me know and I will add documentation, open an issue, and submit a pull request.

Otherwise, I'll just use my modified build of KOS until the new steering becomes adequate for my purposes.

[erendrake]

Well I went ahead and encapsulated the old steering logic and added a bound variable flag to enable/disable it. Took about 1 hour.

If the dev team is interested in this, let me know and I will add documentation, open an issue, and submit a pull request.

Otherwise, I'll just use my modified build of KOS until the new steering becomes adequate for my purposes.

It would be helpful if you have a script and craft that can only work under the old system for us to test with. This is only the first version of the new system and there is surely work to do to improve it. We are interested in finding out why the new one may not be as good out of the box for some applications and find a way to improve it. All of my tests were very positive in the new system but i almost never fly spaceplanes.

I dont think anyone who is active on the dev team is interested in including the old system. It was demonstratively broken in far too many situations.

[tewpie]

It would be helpful if you have a script and craft that can only work under the old system for us to test with. This is only the first version of the new system and there is surely work to do to improve it. We are interested in finding out why the new one may not be as good out of the box for some applications and find a way to improve it. All of my tests were very positive in the new system but i almost never fly spaceplanes.

I dont think anyone who is active on the dev team is interested in including the old system. It was demonstratively broken in far too many situations.

Here you go. https://www.dropbox.com/s/xeox6pkn6f5rgna/drake.zip?dl=0

I have no problems flying that with mechjeb or pilot assistant, or kos .17. There's no set of tuning parameters (all 6+ of them per axis) that I can find that can steer this ship without either overshooting on pitch change or going off course when holding a certain pitch. Having to have separate tuning depending on your altitude/speed is ridiculous, I'd rather write my own custom control loop than do that.

[Dunbaratu]

Here you go. https://www.dropbox.com/s/xeox6pkn6f5rgna/drake.zip?dl=0

I have no problems flying that with mechjeb or pilot assistant, or kos .17. There's no set of tuning parameters (all 6+ of them per axis) that I can find that can steer this ship without either overshooting on pitch change or going off course when holding a certain pitch. Having to have separate tuning depending on your altitude/speed is ridiculous, I'd rather write my own custom control loop than do that.

I tested your craft and script on 0.17.3 (with minor edits to comment out the 0.18 - specific code and change 'groundspeed'/'surfacespeed') and I also tested it on 0.18.1.

The claim that it doesn't work well in 0.18.x is an extreme exaggeration. It's a little bit more fiddly (your plane has extremely weak pitch and roll and yaw authority, by the way, and was quite hard to even fly manually), but it does work.

The thing you didn't mention, which was super important, is that your script is built on very very tight hardcoded assumptions with no tolerance for deviation of any kind. Even on the successful 0.17.3 launch, it ended the launch like so:

Pe = 70,143

Ap = 70,222

Remaining liquidfuel for ascent engine: 19.68 / 1125 (not counting the much larger tank, which because it's feed was disabled I'm assuming was intended as a passive payload).

You never mentioned that you were operating on such razer-thin margins, and that the real problem was that the new steering just made the launch "ever so slightly" less efficient, and your setup could tolerate no deviations from that at all. That's sort of important to the complaint that you're making.

[tewpie]

I tested your craft and script on 0.17.3 (with minor edits to comment out the 0.18 - specific code and change 'groundspeed'/'surfacespeed') and I also tested it on 0.18.1.

The claim that it doesn't work well in 0.18.x is an extreme exaggeration. It's a little bit more fiddly (your plane has extremely weak pitch and roll and yaw authority, by the way, and was quite hard to even fly manually), but it does work.

The thing you didn't mention, which was super important, is that your script is built on very very tight hardcoded assumptions with no tolerance for deviation of any kind. Even on the successful 0.17.3 launch, it ended the launch like so:

Pe = 70,143

Ap = 70,222

Remaining liquidfuel for ascent engine: 19.68 / 1125 (not counting the much larger tank, which because it's feed was disabled I'm assuming was intended as a passive payload).

You never mentioned that you were operating on such razer-thin margins, and that the real problem was that the new steering just made the launch "ever so slightly" less efficient, and your setup could tolerate no deviations from that at all. That's sort of important to the complaint that you're making.

If you have tuning parameters whereby this craft can achieve orbit on .18, please share. The point is this craft can be orbited with MJ, pilot assistant, or .17. It cannot with .18 (believe me I spent hours fiddling with alternative ascent profiles and tuning parameters, short of writing my own PID loops).

I'm not sure why the thin margin was so important. Isn't that a major part of the rationale behind KoS? Precise control for marginal situations? I would be interested to see how, for example, the eve mammoth ssto fares with the new steering method.

I posted my craft/.ks files as a way to help developers improve the new steering, but apparently my use case isn't valid. Oh well, I have my custom build of .18.1....

Edited November 9, 2015 by tewpie

[Qigon]

If you have tuning parameters whereby this craft can achieve orbit on .18, please share. The point is this craft can be orbited with MJ, pilot assistant, or .17. It cannot with .18 (believe me I spent hours fiddling with alternative ascent profiles and tuning parameters, short of writing my own PID loops).

I'm not sure why the thin margin was so important. Isn't that a major part of the rationale behind KoS? Precise control for marginal situations? I would be interested to see how, for example, the eve mammoth ssto fares with the new steering method.

I posted my craft/.ks files as a way to help developers improve the new steering, but apparently my use case isn't valid. Oh well, I have my custom build of .18.1....

I'll add my 2 cents

Maybe you should see the typical use for cooked control as a less hardcore and more casual user. It may look as now we're having less quality because you are expecting an equal or better behavior for a craft that you invested time on, and you may have skills and time to make better, but that's not the point.

I know some math because I learned pid in engineering school, I program for a living, and I have fun writing kos script eventually, but I'd rather have a robust and maintained core kos than anything else. Because more often than not I'm interested in using kos rather than working on it.

[erendrake]

If you have tuning parameters whereby this craft can achieve orbit on .18, please share. The point is this craft can be orbited with MJ, pilot assistant, or .17. It cannot with .18 (believe me I spent hours fiddling with alternative ascent profiles and tuning parameters, short of writing my own PID loops).

I'm not sure why the thin margin was so important. Isn't that a major part of the rationale behind KoS? Precise control for marginal situations? I would be interested to see how, for example, the eve mammoth ssto fares with the new steering method.

I posted my craft/.ks files as a way to help developers improve the new steering, but apparently my use case isn't valid. Oh well, I have my custom build of .18.1....

We appreciate you taking the time to share your craft/script and im sure it will help us improve the steering. I think that Dunbaratu is saying that in your post where you said you were getting "unreasonable behavior" you could have been more clear upfront. When you are operating on such narrow margins with such low control authority i am actually pleased as punch that the new steering got as close as it did.

We will be making refinements to it over the next few patches and we hope that you continue to give feedback when you can think of improvements for our little mod.

[tewpie]

Qigon: I have no problems with the new steering code being the default behavior. All I was asking for was that the old stuff be retained as a deprecated feature.

I wish the dev team would have a little consideration for backwards compatibility going forward. It's usually a minimal effort to separate out old code paths and retain them as non-default, but toggle-able behavior (my offer is still open for that patch). Your approach of nuking old behavior is not one would expect of a *scripting tool*.

And I'm very well aware of how trivial this all is, but I too happen to be a software engineer and this kind of cowboy stuff is exactly what's wrong with our field today.

[Qigon]

Qigon: I have no problems with the new steering code being the default behavior. All I was asking for was that the old stuff be retained as a deprecated feature.

I wish the dev team would have a little consideration for backwards compatibility going forward. It's usually a minimal effort to separate out old code paths and retain them as non-default, but toggle-able behavior (my offer is still open for that patch). Your approach of nuking old behavior is not one would expect of a *scripting tool*.

And I'm very well aware of how trivial this all is, but I too happen to be a software engineer and this kind of cowboy stuff is exactly what's wrong with our field today.

Well this is where we're supposed to disagree, I don't find it trivial. But in the end it doesn't matter because I'm not a contributor, so I'm not calling the shots. But to be honest I understand and defend the point of view of those guys who continue to deliver amazing new features. I've paid the price of backwards compatibility too many times.

May I suggest that instead of forking you release a separate plugin to go on top of kos? I don't have a clue as to how feasible that is, but it'd give you the freedom to do what you think is correct at the same time that erendrake and Steve also do what they think is correct.

[Waz]

I wish the dev team would have a little consideration for backwards compatibility going forward.

As a counter-point, I find the backwards-compatibility stuff just plain annoying as it prevents fixing real issues. It's generally bad practice to spend any time on compatibility before a 1.0 release.

Things I would even change:

* remove all X that are accessible via SHIP:X and similar - they just bloat the docs, obfuscate code, and waste identifiers.

* fix the scoping rules to be simpler (and more like common languages).

* line ending "." to separating ";".

* "set x to y" to "x = y" (no need for == in if statements, since expressions cannot be statements in kOS).

I'd even change ":" to "." for properties/suffixes.

So I think those who want compatibility should be extremely glad with what there is, in counter-point to how annoying I find it.

[Keith Young]

I'm looking for a way to fly my ship using an Apollo DSKY. Is there a way (relatively easily in c#) where I could tell KOS what to do without having to click and type? I already know how to make KSP recognize the buttons I physically hit. It's down to having some C# code tell KOS to write something such as a retro burn and have it execute.

If not, has anyone found a way to program KOS and run scripts using a Teensy? Seems like this also has potential since a Teensy can basically act as a keyboard, and I'd just have to figure out what to tell the Teensy to write.

Awesome mod!!!

[Dunbaratu]

Is there a way (relatively easily in c#) where I could tell KOS what to do without having to click and type?

One of the next features on deck is inter-cpu communication, where a kos CPU has a message queue of prmitive objects (strings, numbers, etc) that other kos CPU's can insert into, so as long as you invent your own protocol for what you want those strings and numbers to actually mean, you can have one talk to another and feed it information.

It occurs to me it might be possible to also add a few external C# hooks into the system so mods can use it to send/receive data from a kOS CPU script, provided the script was written to expect what it's being given. Not a promise - just brainstorming here.

[Qigon]

Qigon: I have no problems with the new steering code being the default behavior. All I was asking for was that the old stuff be retained as a deprecated feature.

I wish the dev team would have a little consideration for backwards compatibility going forward. It's usually a minimal effort to separate out old code paths and retain them as non-default, but toggle-able behavior (my offer is still open for that patch). Your approach of nuking old behavior is not one would expect of a *scripting tool*.

And I'm very well aware of how trivial this all is, but I too happen to be a software engineer and this kind of cowboy stuff is exactly what's wrong with our field today.

I'm looking for a way to fly my ship using an Apollo DSKY. Is there a way (relatively easily in c#) where I could tell KOS what to do without having to click and type? I already know how to make KSP recognize the buttons I physically hit. It's down to having some C# code tell KOS to write something such as a retro burn and have it execute.

http://www.ibiblio.org/apollo/ArtistDSKY.jpg

If not, has anyone found a way to program KOS and run scripts using a Teensy? Seems like this also has potential since a Teensy can basically act as a keyboard, and I'd just have to figure out what to tell the Teensy to write.

Awesome mod!!!

What about a telnet client? Never heard of teensy but it looks like atmel or pic. One way to do it is rs-232 or equivalent -> customized telnet -> kos

And you can write a c# gui to configure code -> script pairs to be read by telnet client.

Did you actually buy/build a dsky? Send us some videos

[tewpie]

Well this is where we're supposed to disagree, I don't find it trivial. But in the end it doesn't matter because I'm not a contributor, so I'm not calling the shots. But to be honest I understand and defend the point of view of those guys who continue to deliver amazing new features. I've paid the price of backwards compatibility too many times.

It's generally bad practice to spend any time on compatibility before a 1.0 release.

Everyone speaks as if it's moving mountains to both keep compatibility and develop new features at the same time. There is always a cost-benefit balance, but in this case the cost was 1) moving some old code into a new class instead of deleting it 2) adding <10 lines of code for a bound variable flag and 3) adding a few sentences of documentation. It literally took me an hour to do this without any prior familiarity with kOS source code and a very rusty knowledge of C#.

I spoke out because it seems like deprecation wasn't even considered as an option, for whatever reason.

Anyway, I doubt anyone other than me actually cares (that's what I meant when I said trivial), so I'll just shut up now and play ksp.

[Keith Young]

I'm going to make a DSKY as soon as I know it's feasible to make the ship what I want using Verbs and Nouns.

Basically I'm trying to build a simpit and I don't want to have to touch a mouse or keyboard.

It looks like I can try to find a way to write a ks file in the correct folder. The difficulty will be writing to Windows since my current methods write to SD. Not sure yet how to write the files to Windows using the languages I have, and FTDI.

Telnet is interesting. When I saw the demo I thought I might be able to find a way to do it with Raspberry Pi, but I might even be able to find a way to get it to work in the microprocessor itself.

I'm very new to C#, and in particular the KSP API (which seems to have practically zero documentation), so I'll have to read up on the C# hooks.

I'll definitely get videos/pics up (probably in a new thread) when this stuff is starting to come together.

Right now I'm just making sure it's all feasible. So far it's looking good

[inoculator]

Hi all,

I have posted this question in the german sub forum as well, but only in the hope of finding somebody speaking my language ;-)

Nevertheless I give it a try in here.

I know about the issue with "pitch", "roll" and "yaw" for the "r(p,r,y)" direction, but I cannot match this with my tasks and I have hughe doubt about that I am on the right way.

Here ist, what I try to get scripted:

I would like to create a generic launch script, that is able to put the vessel in an orbit with an angle other that 90° (equatorial).

The run command should be simple like this:

run autlaunch(650000,56)

which would bring up the vessel to an orbit at 650km and an angle of 56°N relative to KSC at start.

Here is, what I got up to now:

I have written a script, that is able to launch any regular vertical vessel to any equatorial orbit.

I have also implemented, that the script accepts any angle to the startup, but here it comes to an issue with the angle during launch progress: it changes.

So the task is, to have a given angle at launch time, and to recalculate the heading during launch to the new angle to keep the orbit that way.

Abstract:

//Launch by "autolaunch(orbit_alt,orbit_angle)."

declare parameter my_height.
declare parameter my_orbit.

[...some code...]

lock my_heading to my_orbit + ([CurrentLocationRelativetoKerbinOrKSC] * [SomeStrangeQuaternionOrFaktorToGetNeededHeadingByGivenOrbitAngle]).

[..some other code...]

lock steering to heading(my_heading,my_angle).

[...some more code...]

I hope I descripted the issue in an understandable manner.

Any hints or examples to get my on the right track?

br

Carsten

[Keith Young]

Can kOS do this:

Say I have a program that sends my ship to orbit. At 50,000m I decide I want to limit my ship's angular velocity to 5deg/s.

------------

I can't really open the existing code and add it in, since it would count down 3 2 1 and launch and all that, from 50,000.

How do I make that work?

Could I have for example, inside my main launch sequence program, a check_ang_rate() and on the fly adjust the maximum deg/s, save the KS file MIDFLIGHT, and have my launch code on the next calling of check_ang_rate() notice the updated maximum angular velocity?

I wish this was something I could do in C#, but let's face it, kOS's documentation blows away the documentation made by Squad for their API. Without docs I can't figure out this.that.who.knows.whats_going_on. kOS seems to have everything documented.

Thanks for this mod guys. KSP is awesome, but what you did can take this game to a new level and you documented it better than they did. Bravo!

[Wercho]

Here ist, what I try to get scripted:

I would like to create a generic launch script, that is able to put the vessel in an orbit with an angle other that 90° (equatorial).

The run command should be simple like this:

run autlaunch(650000,56)

which would bring up the vessel to an orbit at 650km and an angle of 56°N relative to KSC at start.

I wrote a launch script to do this. The way I did it was a bit hacky, but worked. With my standard ascent profile, I did some testing and determined that if I launched at a surface heading maybe 5 - 10 degrees further from equatorial than my desired orbital inclination, I ended up about right. Once I got to the high atmosphere and could safely fly with a larger angle of attack, I tried to correct in the bring-up-periapsis stage of launch. The trick to this kind of launch is that you don't want to be changing your surface heading all the time in the atmosphere, so you have to anticipate what orbital inclination a given surface heading will produce once you get high enough in the atmosphere for the atmo to no longer be the limiting factor.

A more technical way would be to do something like calculate the final orbital velocity needed for the desired orbit, vector-subtract the difference between the orbital velocity and surface velocity at that final orbit, which is based on planetary rotation rate and altitude. Then use what you just calculated (surface relative final orbital velocity) to find your initial launch heading. I bet there are some niggly things I'm not thinking of, but hopefully that will help.

Can kOS do this:

Say I have a program that sends my ship to orbit. At 50,000m I decide I want to limit my ship's angular velocity to 5deg/s.

------------

I can't really open the existing code and add it in, since it would count down 3 2 1 and launch and all that, from 50,000.

How do I make that work?

Hmm, you might be able to accomplish this by having a separate "ang_rate.ks" file that sets a global variable, and have the main program "RUN ang_rate." and then use the global variable. You would then update the helper file while the main program keeps running. I don't know if this would work.

Whenever I want user input in a program, my standard is to control it with some input that isn't important. For instance, you could rebind your rover control to not match the rocket steering keys (in the KSP main menu). Then do this, with a suitable delay between reads to not change it too much:

IF ship:control:pilotwheelsteer < -0.5 {SET ang_rate TO ang_rate - 1.}
ELSE IF ship:control:pilotwheelsteer > 0.5 {SET ang_rate TO ang_rate + 1.}

But to do that, you have to know in advance what you might want to adjust and have a separate control for all of them. (Or you can get complex, and set up a control to switch between values and a control to increment/decrement the value.)

[Alchemist]

Looks like something broke...

KSP 1.0.5 / kOS 0.18.1

And it's a sandbox save (tried both new save and imported from 1.0.4)

[Keith Young]

When making a KS file that only declares a global, after running, it doesn't seem like it looks for the file in the windows computer. It looks like whatever you ran is saved in to memory.

I could be wrong.

But it seems like you can't load the KS in windows, change velocity from 100 to 200, then save and observe a change in your currently running program.

About to try it with functions which return a velocity but I also bet it won't work.

Know any workarounds? I really need to find a way to manipulate some sort of autopilot without keyboard and mouse, and I'm really struggling to do it on my own without API documentation from Squad.

Edit - Doesn't seem to work for functions either. I've even tried running them in the loop to hopefully update them in memory, and I've tried setting globals through the function and setting a velocity to the return value of the function.

Edited November 10, 2015 by Keith Young

[hvacengi]

Looks like something broke...

KSP 1.0.5 / kOS 0.18.1

And it's a sandbox save (tried both new save and imported from 1.0.4)

Can you post your script that goes along with the exception, and possibly the ksp.log or output_log.txt file? That will help us see what's going on under the hood leading up to your error.

[Alchemist]

I've tried some options and any attempt to call doaction ends in this

System.MissingMethodException: Method not found: 'GameVariables.UnlockedActionGroupsCustom'.

Both in career and sandbox.

Looks like kOS fails at checking the career restrictions, probably due to a change in API between KSP versions

For example, let's take a ship and tag a landing gear as "g1" and just run this (I've saved it as ex on volume 1)

set le to ship:partstagged("g1").
for p in le 
{
if p:modules:contains("ModuleLandingGear")
{set m to p:getmodule("ModuleLandingGear").
m:doaction("raise/lower gear", false).}
}

result:

[LOG 01:03:30.958] System.MissingMethodException: Method not found: 'GameVariables.UnlockedActionGroupsCustom'.
  at kOS.Suffixed.PartModuleField.PartModuleFields.CallKSPAction (System.String suffixName, Boolean param) [0x00000] in <filename unknown>:0 
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke (object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder, System.Object[] parameters, System.Globalization.CultureInfo culture) [0x00000] in <filename unknown>:0 
[LOG 01:03:30.975] Code Fragment
File                 Line:Col IP   label opcode operand
----                 ----:--- ---- -------------------------------  
1/ex                    4:23  0034 @0034 br.false +19 
1/ex                    5:1   0035 @0035 pushscope 3 2 
1/ex                    5:6   0036 @0036 push $m 
1/ex                    5:11  0037 @0037 push $p 
1/ex                    5:13  0038 @0038 push getmodule 
1/ex                    5:13  0039 @0039 getmethod 
1/ex                    5:22  0040 @0040 push _KOSArgMarker_ 
1/ex                    5:23  0041 @0041 push ModuleLandingGear 
1/ex                    5:23  0042 @0042 call <indirect> 
1/ex                    5:23  0043 @0043 store 
1/ex                    6:1   0044 @0044 push $m 
1/ex                    6:3   0045 @0045 push doaction 
1/ex                    6:3   0046 @0046 getmethod 
1/ex                    6:11  0047 @0047 push _KOSArgMarker_ 
1/ex                    6:12  0048 @0048 push raise/lower gear 
1/ex                    6:32  0049 @0049 push False 
1/ex                    6:32  0050 @0050 call <indirect> <<--INSTRUCTION POINTER--
1/ex                    6:32  0051 @0051 pop 
1/ex                    6:39  0052 @0052 popscope 1 
1/ex                    7:1   0053 @0053 popscope 1 
1/ex                    7:1   0054 @0054 jump -38 
1/ex                    7:1   0055 @0055 nop 
1/ex                    7:1   0056 @0056 popscope 1 
                        0:0   0057  pop 
                        0:0   0058  EOP 

[LOG 01:03:31.004] kOS: Stack dump: stackPointer = 2
005      kOS.Safe.Execution.VariableScope
          ScopeId=1, ParentScopeId=0, ParentSkipLevels=1 IsClosure=False
            local var $le-iterator is System.String with value = Structure  Iterator
            local var $p is System.String with value = PART(SmallGearBay,tag=g1)
004      kOS.Safe.Execution.VariableScope
          ScopeId=2, ParentScopeId=1, ParentSkipLevels=1 IsClosure=False
003      kOS.Safe.Execution.VariableScope
          ScopeId=3, ParentScopeId=2, ParentSkipLevels=1 IsClosure=False
002 SP-> kOS.Safe.Encapsulation.Suffixes.TwoArgsSuffix`2+Del`2[System.String,System.Boolean,System.String,System.Boolean]
001      _KOSArgMarker_
000      0

Or even - trying to change nametag in the VAB/SPH throws this out (this time not handled by kOS):

[EXC 00:57:46.613] MissingMethodException: Method not found: 'GameVariables.UnlockedActionGroupsStock'.
	kOS.Suffixed.Career.CanTagInEditor (EditorFacility whichEditor)
	kOS.Module.KOSNameTag.PopupNameTagChanger ()
	BaseEvent.Invoke ()
	UIPartActionButton.OnClick ()

[hvacengi]

Based on the testing I've done so far, I'd bet it's an issue that will be solved when we recompile against v1.0.5. I know that the name tag editor wasn't working properly until we updated the compile. I'll have to go test with 0.18.1 to verify though.