[1.3] Pilot Assistant: Atmospheric piloting aids - 1.13.2 (May 28)

[Crzyrndm]

If i install 1.02 my staging got messed up after reversing to VAB and gettin back to Launchpad. 1.0 is fine.

All stages are then in One stage

Logs or I can't help...

[Behemoth1702]

Confirmed on my end. I installed by drag & drop & overwrite.

Built rocket, staged carefully, launch - everything is on stage 0.

Logs:

http://www./download/1uy87cundhno5vq

[Crzyrndm]

Ok, can someone who is having the bug with staging being reset try this. I did find another nullref that had a similar stack trace, but I haven't actually got the staging to reset myself.

If it doesn't fix it, please upload a new log (this one has a few extra logging elements so I can tell exactly what broke)

[Van Disaster]

Ironically using your logging dll cleared up the problem I was having with the one plane that was causing issues... ( well I guess that was a success).

[Crzyrndm]

Version 1.0.3

• Squashed another nullref
  

Hopefully it fixes it for everyone. If not, use the dll from two posts up to generate a log please

Edited January 26, 2015 by Crzyrndm

[Behemoth1702]

1.0.3 fixed the staging stuff for me. Thanks!

[Crzyrndm]

Another tiny bugfix update

• Fixed typo preventing SSAS roll axis re-engaging
  
• Slide modifier added to the SSAS GUI
  

"Slide"

Slide is essentially a modifier to make SSAS ease back into control. It temporarily scales down SAS response and allows the setpoint to follow the craft slightly. A value of 1 is instant full strength engagement and increasing values give steadily slower and smoother enagagement. Every integer value allows the setpoint to "step" once (so the default of 10 lets it shift 10 times).

This hasn't yet made it into the presets.

Documentation

I'm going to slowly be writing an overview / manual for this mod over the next week or so (started here). I don't have a huge amount of time at the moment, so I'll just have to see how far I can get. Comments and suggestions welcomed

[wizzlebippi]

I tried this autopilot yesterday, and I am actually impressed. It works smoothly and accurately captures altitudes and headings like a real autopilot. Would you mind adding an altitude target for vertical speed mode, and the ability to bank to 45 or 60 degrees in a turn?

[Crzyrndm]

I tried this autopilot yesterday, and I am actually impressed. It works smoothly and accurately captures altitudes and headings like a real autopilot. Would you mind adding an altitude target for vertical speed mode, and the ability to bank to 45 or 60 degrees in a turn?

Under options, there is a toggle to show limits which is required for these changes

Altitude target: In Altitude control mode, change the output limit on the altitude controller to the maximum climb rate you want (I don't know how obvious it is, but the altitude controller is actually feeding the VSpeed/AoA control setpoint, so changing it's output limits changes the VSpeed behaviour)

Greater angle of bank: Increase output limit on the first heading controller (defaults to 30. Be warned that very high angles of bank may not be appreciated by the vertical control system. Speaking of, I need to fix that at some point...)

Glad you like the result, it took a lot of experimentation to find a setup that was capable of decently smooth alterations of attitude to suit flying a plane as a plane.

Edited January 27, 2015 by Crzyrndm

[rynak]

I really like this plugin a lot, but the UI is a bit confusing. After using it for 3 days, i still always feel unsure, about when settings are applied, or if it will become enabled/disabled when i click a button. Another thing i don't quite understand, is why disabling control automatically reverts to no SAS at all - even when before activation, i had SAS enabled. I understand this plugin basically overrides SAS, but from a user POV, the pilot assisant and SAS are two different things, so if he had SAS enabled, then enabled the PA, then disabled it, i think he expects things to revert to normal SAS, instead of SAS being entirely disabled.

A few other hints: AoA and yaw limits really shouldn't require to open the SAS limits.... AoA/Yaw is something the user regularily has to adjust, even if he doesnt even understand what the other SAS values mean. Another thing is the window width - the labels for I clamp limits take up the most space and are the reason for the extra width when editing limits... if you were to abbreviate the iclamp labels a bit... i.e. shorten "upper" to "up" and "lower" to "low"... then the window resize might no longer be neccessary.

EDIT: And a minor but confusing bug: the red LEDs not always indicate if the relevant pilot aid is active - sometimes after switching back and forth a bit, they are red even when no pilot aid is active.

Edited January 27, 2015 by rynak

[Crzyrndm]

UI design is not really a strong point of mine, and how the UI is generated doesn't help with that at all (read: it's a real PITA to code Unity UI). I'll see about compressing it down further and dropping the width resizing, however I don't see why one would need to be regularly adjusting output limits?

Another thing i don't quite understand, is why disabling control automatically reverts to no SAS at all

It's not so much that it reverts back to no control at all, but that it doesn't remember the original SAS state. SAS completely over-rides any action Pilot Assistant makes so I had to shut it down to avoid severe bouts of confusion. You can re-enable SAS before disabling Pilot Assistant control (which'll give a giant red alert to say it isn't functioning...) but I never even thought about having it remember the original SAS state (PA is normally a long term thing, so whther SAS was on at the start or not is rather irrelevant)

[rynak]

About the UI... i would propose to mostly redo it as follows: Split it into a readonly status window, and a setup window.

The status window would be minimal and only contain info if PA is active, which programs are active. Optionally (button) it might also display output about current status (Velocities, Heading, Pitch, SAS values and so on). It might also contain a button to globally disable/enable AP.

The second window would be where one enters the settings, and can then press "apply" to make them active. This window could also integrate the preset functionality via load/save buttons.

So in short, seperate windows for output and input.

EDIT: About your question why to adjust AoA limits and such - the default is just 10 degrees, and it reverts to this unless one loads a preset. 10 degrees is not enough for planes that fly high at the limit of the lift they can generate.

Edited January 27, 2015 by rynak

[Crzyrndm]

EDIT: About your question why to adjust AoA limits and such - the default is just 10 degrees, and it reverts to this unless one loads a preset. 10 degrees is not enough for planes that fly high at the limit of the lift they can generate.

I'm just going to hazard a guess that you're not using FAR/NEAR (since my last FAR SSTO cruised at <1 degree AoA in upper atmosphere), and yes that would be a very reasonable reason to change it. If you're constantly using the same craft, you can make a preset with the raised AoA and it will be automatically loaded for that craft (or you can change the defaults in the Pilot Assistant directory which may be a good idea if you're flyin stock).

1) Not having changes happen until an "apply" button is clicked is just not happening. That's a very specific choice I made after using the regex's original SAS PID tuner. Being able to tune in real-time is so much easier for me.

2) I have a feeling I'm misunderstanding what you want to see in an output window. If it's just current target's + some information that's readily available from the stock GUI or mods such as KER(VSpeed, attitude, control outputs), I don't see why I should duplicate that.

[rynak]

Yep, not using far/near.

About generally not wanting a seperation between input and output.... well, in that case you might have to come up with a new input-scheme, because settings being applied in realtime, while typing in numbers, does not seem a recipe for stability to me - Start typing in 10000...... 1... 0....(nose dives down)..... if UI is not your strong point, then i think what you're trying to achieve might be above your abilities. The input/output seperation i suggested, because it works and is easy to understand for you as well as the user.

EDIT: About outputting things like heading: You ARE already duplicating that... and that's a good idea, because from an interface pov, its useful having the "current value" and "target value" right next to each other, for easy comparison (instead of having to go back and forth across the screen, because related numbers are at different places). I'm talking about horizontal mode for example being in heading-mode, and seeing the current and target heading next to each other. Same for pitch, velocities, and so on - of course, only if its relevant to the current mode.

Edited January 27, 2015 by rynak

[Crzyrndm]

because settings being applied in realtime, while typing in numbers, does not seem a recipe for stability to me - Start typing in 10000...... 1... 0....(nose dives down).....

Setpoints do use an accept button (not applied in realtime unless using WASD adjustment), all tuning parameters have increment/decrement buttons to making tweaking easier (as tuning input is all applied in realtime).

I have duplicated information right where it is required. Splitting it off into a seperate window is what I find difficult to understand

[Crzyrndm]

Pilot Assistant v1.1 released (KSP AVC server appears to be down atm, I'll get that updated when I can. E: Updated AVC to 1.1)

• Pilot Assistant has a test version of Throttle/Velocity Control. Currently is just straight velocity => throttle setting, but I'm considering cascading it to make throttle transitions smoother (cascade would be: Velocity => Acceleration => Throttle)
  
• Controller support for SSAS, Pilot Assistant Heading Control, and Pilot Assistant Vertical Control. No support for the new Throttle Control because most throttles don't run to a negative output
  
• SSAS "Slide" Parameter now supported by SAS presets
  

Throttle/Velocity Control

Give it plenty of Kd and keep Ki low relative to Kp. Jet's have a delayed response so lots of integral will just get it in trouble. The defaults seemed to work reasonably well in testing, but I only tried it on the basic jet...

Standard KSP input methods supported (shift == +Throttle etc.), respects fine control and the modifier key as usual, Max Throttle Keybind sets the target to 2400m/s (surface relative) which may or may not be enough to be useful. Outputs limits are hard locked between 0 and 1 (I really should do that for the three axis controllers as well)

Feedback on how acceptably throttle response can be tuned would be appreciated

Edited January 28, 2015 by Crzyrndm

[Goddess Bhavani]

I'll get to testing this soon. I like the idea of having a proper autopilot for those long haul survey flights.

[Crzyrndm]

So while I think about it, any idea's for additional keybindings that could be useful? (See last page for current list)

So far I'm thinking: toggle SAS mode (actually, maybe SSAS Arm should also toggle modes...), and toggle Asst Hdg/Vert/Throttle active

There's also the question of which key's to use for said functions...

[BaseDrifter]

Hey Crzyrndm, love the mod. It makes flying spaceplanes a whole lot less tedious. No more having to pulse S to keep the pitch where I want it and no more crazy yaw movement!

That said, I'm having some trouble with my larger cargo planes. The assistant works perfectly with smaller craft, but once I step up to medium or large sized planes it doesn't seem to hold the pitch correctly. If I don't use PA, I can hold the craft at the correct pitch to fly it, but as soon as I turn on PA control, the pitch input indicator seems to go back to the neutral position causing premature plane to ground contact.

Any idea why I'm having so much trouble with larger planes? Is there a setting I need to adjust? Maybe it's due to the larger AoA needed with my larger crafts?

Note: Not using FAR or NEAR, stock aerodynamics for now.

Thanks!

[Crzyrndm]

Any idea why I'm having so much trouble with larger planes? Is there a setting I need to adjust? Maybe it's due to the larger AoA needed with my larger crafts?

Probably is since the default AoA limit is 10 degrees (little too high for FAR, way to low for stock...).

Options => Show PID Limits => True

Vertical Speed Controller => Output Limit is max allowable AoA angles. You can probably just set that to something very high (30-40 degrees) with stock since you can't flip out like you can in FAR (the only danger is trying to climb without enough forward speed to retain control). Might want to increase the Integral Limit to be safe as well.

Larger crafts will also probably need a lot more Kd than you are used to in the same controller (they tend to respond a lot slower).

PS

If you go into the PA directory, there will be a "defaults.cfg". That contains the default presets that will be loaded the first time a craft is used. Create a MM Patch (so updates don't overwrite it) to point at the VSpeed controller and make the default a whole lot higher (I'll probably be adding one with the next release anyway...).

This should be close to what you want (I can't check the exact names right now...)

@PIDPreset[default]:NEEDS[!FAR]
{
     @AoAController
     {
          @MaxOut = 30
          @MinOut = -30
     }
}

Edited January 30, 2015 by Crzyrndm

[Crzyrndm]

Version 1.1.1

• Fixed GUI style leakage
  
• Added Throttle controller to presets
  
• Added SAS mode to craft presets
  
• Added AoA default override patch for non-FAR users
  
• Added new keybindings for toggling Pilot Assistant functions
  

I finally caught something like this consistently on a local install (no idea which mod it was...), so I can now say that it should definitely be fixed.

SAS mode in the presets means you can choose which SAS tuner pops out by changing the default. "SASmode = true" => stock tuner, false is the SSAS GUI. If will also override for any craft preset (so some craft can load SSAS by default and others can load the Stock tuner.

Key bindings (If you have a bettter suggestion for the Asst toggles, I'm all ears...)

Modifier + SAS Toggle now toggle SAS mode as appropriate

SAS Hold (default: F) refreshes the SSAS target

numpad 9 toggle Pilot Assistant Heading Controls

numpad 6 Toggles Vertical controls

numpad 3 Toggles Throttle controls

Stock AoA Patch sets the default angle of attack maxima to +/- 30 degrees if you don't have FAR installed.

Edited January 30, 2015 by Crzyrndm

[eddiew]

Ooo, many versions since I first tried this mod last year - time for another bash I think

I hate to ask, but is there an idiots' guide (or paragraph) for "How to fly freely with WASD, but with less wobbles than stock SAS"? I can see the power of this mod, but I feel a little overwhelmed by the number of settings and the terminology and I end up panicking and just piloting manually to orbit instead, wobbles and all ^^;

[Crzyrndm]

So in other words, how to tune the Assistant controllers for stable flight?

Some tips

http://forum.kerbalspaceprogram.com/threads/100073-0-90-Pilot-Assistant-Atmospheric-piloting-aids-1-1-1-%28Jan-30%29?p=1631919&viewfull=1#post1631919

http://forum.kerbalspaceprogram.com/threads/100073-0-90-Pilot-Assistant-Atmospheric-piloting-aids-1-1-1-%28Jan-30%29?p=1588253&viewfull=1#post1588253

PID in a spreadsheet: https://docs.google.com/spreadsheets/d/14HopZx8l7g4gGfQU0BZhxjjyEOzr5fQ8puNg8_44b1g/edit#gid=0 (make a copy of it and you can change numbers and see what sort of effect they have)

You can also use the throttle control to safetly experiment (since speed oscillations won't make you fall out of the sky unless you're going really slow)

I'll get to writing a full tutorial here, but it's going to take a while

It's best if you can describe your issue since otherwise I can only start with the common issues and work down the list

EDIT

*angry muttering about forgetting to update my own mods on full install*...

Edited January 30, 2015 by Crzyrndm

[eddiew]

Hehe, to be honest, that spreadsheet is exactly what I mean by overwhelmed I have zero technical background (I'm a web developer as my day job, but that's not really relevant to aeronautics) and the whole Kp, clamp, integral, derivative, etc, terminology just makes me stare at the screen with my jaw slightly ajar.

Basically my 'issue' is my own brutal ignorance of the subject at hand - and in all honesty, a lack of interest/time enough to read long articles about PID controllers ^^; I am very much interested in mods that smooth out flight behaviours in KSP, but truthfully I don't care how or why they work, I just want the plane to fly 'better' and not be rolling left-right-left-right to dangerous degrees as often happens on the stock SAS at high altitudes

Really, I'm kinda hoping for a short cheat sheet in terms of the controls that are actually on the screen, for example:

- press button A to engage pilot assistant (I can work that out, tbh, but it's good to begin at the beginning )

- if the craft has pitch wobble, open panel B, increase setting C. If it is hard to change pitch, reduce setting C.

- same for yaw and roll wobbles

This alone would be awesome (and your second link might actually be these exact instructions, and I have yet to check because it's now 1am and I really need to sleep) An advanced topic for the cheat sheet might be pitch hold...

- to hold a given pitch, hit button D, enter desired angle above the horizon (I can find that too, but last time I tried it couldn't hold the requested angle, resulting in the next bit...)

- if the nose doesn't match the entered pitch even though you can manually point the plane at that angle, open panel E, adjust value F upwards until it does

- if this introduces instability and flips the plane, lower your expectations, or review your design, because there's only so much we can do with PID

Absolutely appreciate all the work you've put into this mod so far, the goal is noble, but I do wonder if the GUI might be a little more... intuitive, for the newcomers? It's great that you've been working to reduce the numbers we're shown, but sometimes there's still a question about what that number means, and which way should it change to get a desired effect. My suggestion, based on my incomplete understanding of the problem, would be sliders for each of pitch, yaw, and roll:

Responsiveness |---------[]---| Damping

I think a lot of people (including myself) would be a lot less intimidated by this format, if it would be practical to implement It seems very common-sense that oscillation damping and responsiveness are opposites on the scale, and really the goal of anyone tuning their SAS is going to be to find the best balance between the two such that their plane stops trying to tip, flip, spin, or roll out of control while still being controllable. You could probably provide 20 positions, and most of us would find something along that slider that is better than stock.

I'm sure that the various Kp, Kd, etcs, do have their uses in the right hands, and should be kept available - but mine are not those hands. And in all honesty, I suspect a lot of people are a bit bamboozled by them as well. Unless I am actually the special kid in the class, which is certainly possible

[Crzyrndm]

Unless I am actually the special kid in the class, which is certainly possible

Somehow I doubt it.

To put it bluntly: At the end of the day I wrote this to make my life easier, making it useful for others has always been a somewhat secondary concern. If it wasn't for the need to find space in the GUI, I'd probably have even more numbers showing up

The shorthand of it is actually rather simple (using the stock SAS tuner).

• Open the axis which is giving you issues
  
• If the issue is rapid oscillations/vibrations, increase the value marked as Scalar (just slowly tick it up with the increment buttons, sometimes it doesn't take much for it to dissapear)
  
• If the issue is a large slow wobble (Imagine the stereotypical cartoon drunk sway) decrease the value marked as Scalar
  

Increasing speed brings you get closer to the rapid oscillations, while increasing altitude gets closer to the drunken flailing

The Asst is pretty much the same thing, however identifying the controller to change the scalar is slightly less straight forward and some messing with the tuning constants will be required (except the throttle control, that's nice and straight forward) . If you want to keep it light on the unmbers, just stick with stock SAS and the scalars.

Edited January 31, 2015 by Crzyrndm