[1.3] kOS Scriptable Autopilot System v1.1.3.0

[Cakeofruit]

This is how i get the AoA

FUNCTION AOA {

RETURN VANG(ship:facing:vector, ship:srfprograde:vector).

}

[idPhobos]

...In the meantime you can do the fix manually yourself - just use VCXL(SHIP:VELOCITY:SURFACE, SHIP:UP:VECTOR) and it *should* work.

Great, I did wonder if it was that issue. I remembered it being a problem with KER a while back.

I'll try the vec exclude tonight (was late and I had only tried a subtract of vertspeed to work around, was closer but still not correct ).

Edited November 5, 2015 by idPhobos

[erendrake]

Github https://github.com/KSP-KOS/KOS/releases/tag/v0.18.0

[h=3]BREAKING CHANGES[/h]

• As usual, you MUST recompile all KSM files before running them on the new version. Some of the changes have altered how the VM works.
  
• New LOADDISTANCE obsoletes the previous way it worked ( http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html )
  
• Fixed broken spelling of "ACQUIRE" on docking ports. The old spelling of "AQUIRE" won't work anymore.
  
• Changed the bound variable "SURFACESPEED" to "GROUNDSPEED" instead, as the meaning of "SURFACESPEED" was confusingly ambiguous.
  
• New arg/param matching checks make some previously usable varying argument techniques not work. (We don't think anyone was using them anyway).
  
• Disabled the ability to control vessels the kOS computer part is not actually attached to. This always used to be possible, but it shouldn't have been as it breaks the theme of kOS. This affects all the following: vessel:control, part:controlfrom, part:tag (can still get, but not set), partmodule:doaction, partmodule:doevent, partmodule:setfield (can still getfield). These things become read-only when operating on any vessel other than the one the executing kOS module is actually part of.
  

[h=3]NEW FEATURES[/h]

• THE BIG ONE: Fix to Cooked Steering! Should help people using torque-less craft like with Realism Overhaul. Removed the old steering logic and replaced it with a nice auto-tuning system. ( #1118 )
  
• SteeringManager structure to let users tweak parts of the new steering system ( http://ksp-kos.github.io/KOS_DOC/structures/misc/steeringmanager.html )
  
• PIDLoop structure to let users see parts of the new steering system, and to let them use the built-in PID system for their own needs ( http://ksp-kos.github.io/KOS_DOC/structures/misc/pidloop.html )
  
• String manipulation methods. ( http://ksp-kos.github.io/KOS_DOC/structures/misc/string.html)
  
• New Lexicon (Associateive Array) type. ( http://ksp-kos.github.io/KOS_DOC/structures/misc/lexicon.html )
  
• New Science Experiment control interface allows scripts to directly execute science experiments, bypassing the on-screen prompts. ( http://ksp-kos.github.io/KOS_DOC/structures/vessels/scienceexperiment.html )
  
• CrewMember API to let you query the registered crew - their class, gender, and skill (http://ksp-kos.github.io/KOS_DOC/structures/vessels/crewmember.html )
  
• Infernal Robotics API now lets you get Part containing a servo ( #1103 )
  
• (user docs) Better tutorial for KSP 1.0 areo mode. ( #1081 )
  
• A few more constants: C, ATMTOKPA, KPATOATM. ( http://ksp-kos.github.io/KOS_DOC/math/basic.html )
  
• DYNAMICPRESSURE, or Q ( #1085 )
  
• DEFINED keyword ( http://ksp-kos.github.io/KOS_DOC/language/variables.html#defined )
  
• Load and Pack Distance manipulation ( http://ksp-kos.github.io/KOS_DOC/structures/misc/loaddistance.html )
  
• KUniverse structure letting you break the 4th wall and revert from a script ( http://ksp-kos.github.io/KOS_DOC/structures/misc/kuniverse.html )
  
• Added SolarPrimeVector to provide universal longitude direction ( http://ksp-kos.github.io/KOS_DOC/bindings.html#solarprimevector )
  

[h=3]BUG FIXES[/h]

• Made stage:liquidfuel more sane. ( #513 )
  
• LIST BODIES returned unusuable structure type ( #1090 )
  
• Made "ORBIT" and alias for "OBT" and visa versa ( #1089 )
  
• Made vecdraws stop showing bogus atmospheric burning effects ( #1108 )
  
• Removed non-functional broken attempts to save/restore variables ( #1098 )
  
• KSM files didn't store relative jumps right, breaking short-circuit boolean logic ( #1137 )
  
• (user docs) many minor docs fixes.
  
• Lock throttle inside a FROM loop was broken ( #1117 )
  
• Unlock anything inside a Trigger body was broken ( #1151 )
  
• Replaced KSP's incorrect ground speed with our own calculation ( #1097 )
  
• SASMODE "radialin" and "raidialout" were swapped in the KSP API ( #1130 )
  
• Bug with remote tech allowing access without antenna in one case ( #1171 )
  
• Wheelsteering by integer compass heading was broken ( #1141 )
  
• SHUTDOWN didn't shut down immediately ( #1120 )
  
• Remote Tech delay, and the wait command, were ignoring the time warp multiplier ( #723 )
  
• Better detection of arg/param matching. ( #1107 )
  
• Doing PRINT AT that runs offscreen threw an error ( #813 )
  

[Horus]

Bless you!

[idPhobos]

Well that fixes my little issue rather spectacularly.

[Cakeofruit]

this update freeze my ksp loading when the kos part are patch with the module manager.

I play on a mac and it's the only mod install

[idPhobos]

this update freeze my ksp loading when the kos part are patch with the module manager.

I play on a mac and it's the only mod install

Hangs when MM is patching kOSMachine0m. Narrowed it down to KER in my case. Still doing A B tests to see if it's also with another mod.

Edit: Not just KER. KIS/KAS too.

Tail of log

[LOG 20:21:49.972] DragCubeSystem: Creating drag cubes for part 'KIS.evapropellant'[LOG 20:21:49.988] PartLoader: Compiling Part 'KIS/Parts/guide/part/KIS_guide'
[LOG 20:21:49.996] PartLoader: Part 'KIS/Parts/guide/part/KIS_guide' has no database record. Creating.
[LOG 20:21:50.000] DragCubeSystem: Creating drag cubes for part 'KIS.guide'
[LOG 20:21:50.017] PartLoader: Compiling Part 'KIS/Parts/wrench/part/KIS_wrench'
[LOG 20:21:50.025] PartLoader: Part 'KIS/Parts/wrench/part/KIS_wrench' has no database record. Creating.
[LOG 20:21:50.029] DragCubeSystem: Creating drag cubes for part 'KIS.wrench'
[LOG 20:21:50.040] PartLoader: Compiling Part 'kOS/Parts/kOSMachine0m/part/kOSMachine0m'
[EXC 20:21:50.055] FileNotFoundException: Could not load file or assembly 'KSPAPIExtensions, Version=1.7.5.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies.
    System.MonoCustomAttrs.GetCustomAttributesBase (ICustomAttributeProvider obj, System.Type attributeType)
    System.MonoCustomAttrs.GetCustomAttributes (ICustomAttributeProvider obj, System.Type attributeType, Boolean inherit)
    System.Reflection.MonoField.GetCustomAttributes (System.Type attributeType, Boolean inherit)
    BaseFieldList.CreateList (System.Type type, System.Object instance)
    BaseFieldList..ctor (UnityEngine.Component host)
    PartModule.ModularSetup ()
    PartModule.Awake ()
    UnityEngine.GameObject:AddComponent(Type)
    Part:AddModule(String)
    Part:AddModule(ConfigNode)
    PartLoader:ParsePart(UrlConfig, ConfigNode)
    :MoveNext()
[EXC 20:21:50.058] NullReferenceException: Object reference not set to an instance of an object
    PartModule.Load (.ConfigNode node)
    Part.AddModule (.ConfigNode node)
    PartLoader.ParsePart (.UrlConfig urlConfig, .ConfigNode node)
    PartLoader+.MoveNext ()
[EXC 20:21:50.062] NullReferenceException: Object reference not set to an instance of an object
    PartLoader.GetDatabaseConfig (.Part p)
    PartLoader.GetDatabaseConfig (.Part p, System.String nodeName)
    DragCubeSystem.LoadDragCubes (.Part p)
    Part+.MoveNext ()

Edited November 6, 2015 by idPhobos

[hvacengi]

It looks like we forgot to include KSPAPIExtensions.dll in the zip file that we released earlier today. That caused the errors that @idPhobos reported in the log file. Since we have to correct an issue with PIDLoop anyways, we'll get this dll included in the same update. Don't expect the release yet tonight, we'll want to make sure there are no other small fixes to publish at the same time. For the time being, you can copy the dll out of the zip file for 0.17.3.

[idPhobos]

Excellent, back up and running!

[Drew Kerman]

it's not possible at the moment to add more than one kOS CPU to the same part (I tried - two CPUs show up but opening the terminal via the kOS menu highlights both CPUs as opened). Is this a core limitation of kOS or has it just not been implemented as a feature yet? I'm not a fan of the kOS-specific parts and prefer to just MM the kOS module into my existing probe cores. In some cases I would like to run multiple CPUs (one for rocket control, another just for monitoring/logging telemetry) and once again it would be nice to be able to do so with a single part carrying multiple CPUs

[Octa]

Is this the right mod if i want to automate a SSTO flight profile? Right now i'm using Pilot Assistant to keep heading, height or vertical speed at a constant level while it also stabilizes the plane (keeping roll at 0 and adjusting pitch/yaw for heading and climb. Can i do the same here or is there more manual work required in the script? In Pseudo-Code, what i imagine looks like this:

- Start rapiers, disable other engine, full throttle, roll=0, hdg=90

- If speed=100m/s, pitch up a bit (liftoff), retract gear

- pitch=30 degree until 10.000m

- keep vertical speed of 50 m/s until 20.000m

- keep vertical speed of 10 m/s until 25.000m (asuming i run out of intake air at this height)

- switch to closed cycle, close intakes, pitch 45° until Ap is 75.000

- stop engines, turn prograde

As said, right now i'm typing in new numbers into pilot assistant during flight, which handles the actual controls. With a scripted ascend, i want to take most unreliable thing out of the equation (=me) and have something of a comparison between different vessel designs/configuration or flight profiles. ("Hmmm, i have plenty of Oxygen left after i got in orbit, which my nuke does not need, how much can be removed while i still get to space").

This mod offers a huge amount of things that can be configured/scripted, is this sort of automated control possible or do i need to script more things explicitly? For example the sections of keeping vertical speed. Does kOS automatically adjust pitch to keep the climb rate like pilot assistant or do have to scripts the pitch itself (which i think would be a bit more complicated )?

Also, do 2 launches look exactly the same?

[Dunbaratu]

Is this the right mod if i want to automate a SSTO flight profile? Right now i'm using Pilot Assistant to keep heading, height or vertical speed at a constant level while it also stabilizes the plane (keeping roll at 0 and adjusting pitch/yaw for heading and climb. Can i do the same here or is there more manual work required in the script? In Pseudo-Code, what i imagine looks like this:

Short answer: yes.

Longer answer: yes, BUT... all the mod does is provide a toolkit you can use to write the software yourself, so you still have to figure out the algorithm of how you're going to do it.

- Start rapiers, disable other engine, full throttle, roll=0, hdg=90

- If speed=100m/s, pitch up a bit (liftoff), retract gear

- pitch=30 degree until 10.000m

- keep vertical speed of 50 m/s until 20.000m

- keep vertical speed of 10 m/s until 25.000m (asuming i run out of intake air at this height)

- switch to closed cycle, close intakes, pitch 45° until Ap is 75.000

- stop engines, turn prograde

Everything on that list should be doable from kOS, in principle.

This mod offers a huge amount of things that can be configured/scripted, is this sort of automated control possible or do i need to script more things explicitly? For example the sections of keeping vertical speed. Does kOS automatically adjust pitch to keep the climb rate like pilot assistant or do have to scripts the pitch itself (which i think would be a bit more complicated )?

Also, do 2 launches look exactly the same?

There are small differences in behavior from one run to the next due to the fact that the environment outside the KSP game indirectly affects the game's simulation rate. i.e. if you ran KSP while your computer was trying to, say, process a video or calculate Pi to several million places, that can cause it to use slightly longer time deltas between simulation frames, as the OS isn't allowing it as much of the CPU's time. Those slightly longer time steps can cause variations that feel random as far as your script is concerned. But they generally only cause a small bit of "noise" in the behavior, so to speak.

The main trick to all the things you're trying to do is to use a PID control algorithm. You could seek a certain climb rate as your target setpoint, and use that PID controller's output to set the elevator pitch. If you look over in the reddit group /r/kos, it has some useful sidebar information about how a PID control algorithm works and how you make one, and the new release of kOS is supposed to have a helpful library to do the math for you (but wait for tomorrow when the 0.18.1 patch is released first - that PID control part of the mod had a small error in today's 0.18.0 release that's getting patched tomorrow and re-released.)

[Octa]

Short answer: yes.

Longer answer: yes, BUT... all the mod does is provide a toolkit you can use to write the software yourself, so you still have to figure out the algorithm of how you're going to do it.

Everything on that list should be doable from kOS, in principle.

There are small differences in behavior from one run to the next due to the fact that the environment outside the KSP game indirectly affects the game's simulation rate. i.e. if you ran KSP while your computer was trying to, say, process a video or calculate Pi to several million places, that can cause it to use slightly longer time deltas between simulation frames, as the OS isn't allowing it as much of the CPU's time. Those slightly longer time steps can cause variations that feel random as far as your script is concerned. But they generally only cause a small bit of "noise" in the behavior, so to speak.

The main trick to all the things you're trying to do is to use a PID control algorithm. You could seek a certain climb rate as your target setpoint, and use that PID controller's output to set the elevator pitch. If you look over in the reddit group /r/kos, it has some useful sidebar information about how a PID control algorithm works and how you make one, and the new release of kOS is supposed to have a helpful library to do the math for you (but wait for tomorrow when the 0.18.1 patch is released first - that PID control part of the mod had a small error in today's 0.18.0 release that's getting patched tomorrow and re-released.)

Thanks for your answer!

From 1st thought, the Noise created by other programs than KSP can be ignored. When i start KSP, usually no other Program (apart from the always running background applications like steam) is running. Or the design/ascent path must be bleeding edge with no margin of error/variation.

So after digging a bit more in the documentation, i found that that stuff like vertical speed and heading are RO parameters, so i'd have to write the loop that read the current values and and adjust the control (pitch, roll, yaw) if theres a difference. So no pre-programmed auto-pilot where i can set "waypoints" of the ascent.

I haven't yet decided if this goes too deep into material for me or not. I already spend much time on playing KSC or messing around with computers/servers, with scripting in KSP/kOS there would much less free time left for other things

[tewpie]

I don't like the new cooked steering at all. The old algorithm worked reasonably well for most cases, and I could roll my own PID loop if it didn't. This new one REQUIRES hand tuning of pid values and/or torque/stopping time for almost every ship to get reasonable behavior, which I find tedious and unnecessary.

Please add back option to use the old control scheme... the new PIDLoop structure is great and simplifies custom PID loop scripting, but taking away the old cooked steering and forcing the use of PID loops seems to be a step backwards.

[Dunbaratu]

Please add back option to use the old control scheme...

Probably never going to happen. That would be a spaghetti code nightmare to maintain as they are two entirely different systems with different code flow.

the new PIDLoop structure is great and simplifies custom PID loop scripting, but taking away the old cooked steering and forcing the use of PID loops seems to be a step backwards.

The only problem I've seen is that the default tuning parameters make it steer too weakly for the case of a large rocket that is slow to turn and needs the controls pushed to the max. I just think that the default settings need to be a bit rebalanced, rather than scrapping everything and making the system a spaghetti code mess by trying to support both the old and new systems.

Opening up the chance of tuning the built-in steering without having to make your own entire steering system from scratch isn't a step backward at all. In the old way you had to replace the entire steering system with your own work from scratch in order to get even the slightest change to the behavior. The only options you had were "use hardcoded behavior" or "do the whole thing yourself". There were no in-between options. Now there are.

Edited November 6, 2015 by Steven Mading

[BevoLJ]

Is there a way to do RCS directional burns? Looking to automate my ullage for to automate starting my engines. Currently to start burns I'm just disabling the engine, thrust to 1 with RCS active, then when they have fuel re-enabling my engines. Just wondering if it could also be done with RCS w/o needing to disable the engines prior to burns. I can't seem to find much on RCS in the documentation, unless I am just looking in the wrong place. Would also be nice to know if RCS directional burns are possible since that is how I do finetune most of my orbital adjustments in RSS.

Edited November 7, 2015 by BevoLJ

[tewpie]

Unless I'm missing something, no set of default PID values can replace the flexibility of the old steering code which accounts for both torque and inertia, and seems to handle non-linear torque situations well (such as pitching with significant drag present). As an example, the old steering worked great, without any tuning, with my multistage spaceplane which has vastly different mass, cg and torque depending on the phase of flight. Now I have to have 3 separate sets of PID values for takeoff, atmospheric flight, and space flight to get good behavior.

Probably never going to happen. That would be a spaghetti code nightmare to maintain as they are two entirely different systems with different code flow.

Maintainability is not valid reason to take away working, useful features. There are ways to have legacy code live side by side with newer stuff....

[Drew Kerman]

Maintainability is not valid reason to take away working, useful features

It sure is when you're doing this as a hobby in whatever spare time you manage to make for it. Why would the devs willingly make things more difficult under those circumstances? They are already giving you all this awesome capability for free.

And are any of the devs able to answer my question posed earlier?

Edited November 7, 2015 by Gaiiden

[erendrake]

It sure is when you're doing this as a hobby in whatever spare time you manage to make for it. Why would the devs willingly make things more difficult under those circumstances? They are already giving you all this awesome capability for free.

And are any of the devs able to answer my question posed earlier?

For your question. I simply have never tried it and we dont test for it. I think that having an advanced kOS part with 2 would be fun and useful. Do we have an open issue in github about it? if not would you mind creating one and we can put it in the roadmap

[Camacha]

The new PIDloop stuff seems interesting Even though I always rather enjoyed implementing a good PID controller, when it is about the purpose and not the means, this could be helpful. The only thing I do not see working is implementing more advanced PID features (jolt and/or jitter protection, for instance), though the ability to dynamically set minima and maxima somewhat mitigates that.

The reverting option is nice too. I was toying with the idea of writing an external program for a couple of experiments, but now kOS makes it very possible to do that from KSP itself (though I am not sure about processing speed).

I see kOS has proper functions now too. How neat You made wonderful progress in my absence. Colour me impressed, gentlemen!

Edited November 7, 2015 by Camacha

[tewpie]

It sure is when you're doing this as a hobby in whatever spare time you manage to make for it. Why would the devs willingly make things more difficult under those circumstances? They are already giving you all this awesome capability for free.

*sigh*

welp, looks like I'm branching kos and building my own version with the old steering logic. And having read the code, I fail to see how the 1500 lines of undocumented new steering code is more maintainable than the 200 lines of undocumented old code.

[Camacha]

Why does this remind me of XKCD?

[hvacengi]

Unless I'm missing something, no set of default PID values can replace the flexibility of the old steering code which accounts for both torque and inertia, and seems to handle non-linear torque situations well (such as pitching with significant drag present). As an example, the old steering worked great, without any tuning, with my multistage spaceplane which has vastly different mass, cg and torque depending on the phase of flight. Now I have to have 3 separate sets of PID values for takeoff, atmospheric flight, and space flight to get good behavior.

I wrote the new steering code, and based on your above comment I'm not sure you fully understand the differences between the new code and the old code. So let me try to help with that.

Previously:

Steering was handled using a "guess" at what the turning angular velocity should be based on angular offset. Then the available torque was calculated for the vessel, based only on torque wheels and a rough calculation of RCS torque. There was no feedback to the control loop, and in fact is was implemented statically so that it did not remember anything about even the previous setpoint. In some instances, this was close enough to work well, while in others (most notably instances without RCS or torque wheels). 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.

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.

I agree fully that installing blind PID controls that require the user to tune them would defeat the purpose of cooked steering (to be a fairly simple default default steering control). In an ideal world where we have access to all of the variables and computing power is infinite, a fully deterministic calculation would be far superior. However, that calculation is what the physics engine behind KSP is already doing and we cannot practically replicate or approximate it without taking some short cuts (otherwise the control calculation literally doubles the execution time). What the new steering code does is blend the two choices as practically as possible. Because we (all of the KSP developers) agree that this calculation will not be perfect in every instance, it was important to us that the tuning parameters be exposed to give the user the choice of how the steering should perform.

It is important to note that the old steering code was not in any way a fully deterministic calculation for steering. It ignored several more factors than today's code does. If failed miserably when there were small values for available torque, as well as when the available torque was significantly larger than it needed to be. When using gimbaled engines, it often oscillated wildly. These are all things that were supported by a variety of issues posted to github, posts on reddit, comments made by streamers and youtubers, and in this thread. It was not broken for all ships, but it was indeed broken for some ships, and it provided no way for the user to fix this. The stock SAS is not perfect for all ships either (it creates oscillations in the orbit itself when torque is very high for small mass ships), nor is MechJeb's (I've had instances of uncontrollable pitch oscillation on more than one occasion, and I never could make it work well for planes).

Maintainability is not valid reason to take away working, useful features. There are ways to have legacy code live side by side with newer stuff....

I wanted to pull this quote out separate from the rest, so that I could address it directly. Maintainability is a valid reason for removing a feature, especially a broken feature. When code becomes as complicated and patched together as the old steering code was, it becomes very difficult to trace out bugs. Add the fact that no one who wrote that implementation is currently working on the kOS, and you have a receipe for disaster when something breaks (and something always breaks). By re-writing the code, I was able to compartmentalize the code to some degree, putting features into their own classes and methods, which could be both reused elsewhere in the code and tested/debugged separate from the steering code itself. If we had chosen to maintain two tracks of steering, the answer to any issue with legacy steering would be "use the new steering".

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. The existing default values were found to work well in initial testing, but there the devs have since found a few places where we want change things up a little bit. We want to invite every one to help with figuring out the tuning by submitting values that worked for you, along with an image of the ship design (or a link to the craft) and preferably the csv output files from the steering manager: http://ksp-kos.github.io/KOS_DOC/structures/misc/steeringmanager.html?highlight=steering#attribute:STEERINGMANAGER:WRITECSVFILES Help us help you... help us... help you?

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.

- - - Updated - - -

it's not possible at the moment to add more than one kOS CPU to the same part (I tried - two CPUs show up but opening the terminal via the kOS menu highlights both CPUs as opened). Is this a core limitation of kOS or has it just not been implemented as a feature yet? I'm not a fan of the kOS-specific parts and prefer to just MM the kOS module into my existing probe cores. In some cases I would like to run multiple CPUs (one for rocket control, another just for monitoring/logging telemetry) and once again it would be nice to be able to do so with a single part carrying multiple CPUs

Well if it wasn't dependent on it before, the new steering code made it so that the part ID is used to differentiate between "subscribed" parts for the steering provider. I do want to fix that by using a "VesselModule" to manage the once per ship objects (like steering manager and flight control). That was too much of an additional undertaking to make this release, but it will probably be in a future release if I can dedicate enough time to figuring out the life-cycle. Honestly, the execution should be tied directly to the "module" itself, rather than the part, which would enable the operation you're expecting. It will probably happen after the revisions to volumes and files in the next "big" release.

I'll look into it a little closer though. Cause it may be that the part tracking should be OK with multiple modules and we just don't have it enabled.

- - - Updated - - -

The new PIDloop stuff seems interesting Even though I always rather enjoyed implementing a good PID controller, when it is about the purpose and not the means, this could be helpful. The only thing I do not see working is implementing more advanced PID features (jolt and/or jitter protection, for instance), though the ability to dynamically set minima and maxima somewhat mitigates that.

Welcome back. I actually had to write a "moving average" class to accomodate some of the other things in the steering code. That might be something that we could consider exposing as a structure in a future release as a way to filter out some of the jitter.

[Drew Kerman]

Damn couldn't rep you again so soon hvacengi but, thanks!

Same with you erendrake. I will create a Github issue, was going to do that originally but decided it might be better to propose the idea here first

[hvacengi]

It's official. I'll be streaming tomorrow at 2PM EST: http://forum.kerbalspaceprogram.com/calendar.php?do=getinfo&e=231&day=2015-11-7