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

[Behemoth1702]

I am comfy with rough mathematic concepts in my head, yes, but the naked numbers, grrr, hate them.

But thank you for the link. I now understand PIDs and can work with them. Already tuning the hell out of the firehound, hehe.

Why are you values set so high? I for example can work just fine in PAssistant with values from 0.1 to 3.

Is it like -

1.2

1.2

1.2

is the same as

12

12

12

?

And what is CLAMP for... Mhh.....

[Crzyrndm]

Hit up google or wikipedia for some background on PID controllers, it'll be more complete than anything I can manage, so I'll just stick to explaining the correlations

Kp/Ki/Kd are the gains for the proportional, integral, and derivative blocks and control how much of the response each is responsible for. Proportional control deals with the current state, integral with the past state, and derivative with the predicted state and they are named after the mathematical actions used to obtain their response (eg. the response of the proportional block is proportional to the current error. response = Kp * error). Proportional does most of the heavy lifting, integral is responsible for bringing the error all the way to zero, derivative dampens the oscillations.

The scalar term is a global value that lets you quickly adjust stability. A scalar of 10 results in a 10x lower output (assuming the clamps are not involved).

There are also two sets of clamps. The ones you have listed (I Clamp Lower/Upper) are responsible for the integral sum only. If for some reason the error could not reach zero and the integral block was active, the integral sum could reach a very large value. If the setpoint was to change, the controller would take a very long time to respond because the integral sum would first have to eliminate all it's excess and while it was doing that it would be overriding any other control. The integral clamps prevent this by imposing limits on the integral sum.

The output clamps are nice and simple. They are purely a clamp on the same of responses from the proportional, integral, and derivative actions.

Each plane behaves very differently, but there are some general guidelines I have found:

• Pitch controls are the one's that are difficult to get right. Roll and yaw you just back off the scalar if it starts getting twitchy and that's basically the end of it
  
• Small agile planes use very little derivative action. The bigger and less agile they are, the more damping (derivative) is needed
  
• The optimal integral gain is generally between 30-60% of the proportional gain (higher means it will zero errors faster, but is more prone to oscillations).
  
• If the integral is too low relative to the proportional, it will oscillate slightly as it approaches the set point. This is because it can't keep up with the handover of control (proportional error decreases => integral can't increase fast enough => error increases => proportional gives it a bump again, etc.)
  
• If the derivative response is too low compared to the proportional response it will only respond once the axis has picked up a lot of speed resulting in large flailing oscillations. If it is too high, any movement on the axis it will over-react to and push it the other way, resulting in rapid jerky oscillations that often travel in the wrong direction (close to a reasonable level, it becomes very difficult to tell the difference between the two actions
  
• As dynamic pressure (Q) increases, control authority needs to decrease slowly, so as it becomes unstable just tick the scalar term up a bit
  
• If playing with FAR, the trans-sonic regime (~Mach 0.75-1.25) results in a sharp spike in pitch instability (I presume due to Mach tuck). As you pass through this region you may need to double or more the pitch scalar
  

I am comfy with rough mathematic concepts in my head, yes, but the naked numbers, grrr, hate them.

But thank you for the link. I now understand PIDs and can work with them. Already tuning the hell out of the firehound, hehe.

Why are you values set so high? I for example can work just fine in PAssistant with values from 0.1 to 3.

Is it like -

1.2

1.2

1.2

is the same as

12

12

12

?

And what is CLAMP for... Mhh.....

Clamp is what PID tuner used instead of scalar (and those numbers are only relevant for the stock PID tuner, just remember). Everything is scaled up by a factor of 1000, hence the huge numbers (you'll see the same on Pilot assistants stock SAS tuning tab)

Using 1.2 vs. using 12 is only the same if you also increase the scalar by a factor of 10!

Edited December 27, 2014 by Crzyrndm

[Wanderfound]

Plug the values shown above into the Stock SAS mode of KPA, and if you're flying a Kerbodyne whatsit it'll perform roughly as intended; that's what I use when I'm test flying 'em.

BTW, Crzyrndm: as suggested above, I use KPA mostly just to tune the stock SAS. I usually don't bother adjusting the PID on the surface SAS because I don't use it. With an untuned SAS, I get pitch oscillations; tuning fixes that.

Sometimes, when I come out of pilot assist mode (which I mostly just use as a long-distance cruise control), pitch oscillations reoccur. It looks like the stock SAS PID tuner isn't taking effect when toggling the pilot assist features off. In the most recent flight, it kept oscillating until I reselected "control from here" on the cockpit. I have no idea why that worked, but it did; pitch wobbles instantly disappeared.

[Crzyrndm]

...which I mostly just use as a long-distance cruise control...

Exactly what it's designed for (although I think you misunderstand what SSAS is. No matter)

I'll take another look at the SAS, sounds like something wierd is going on (although that's been a bit of a constant there since 0.90 dropped...)

[Behemoth1702]

Man, I'm trying hard but for whatever reason a pretty stable plane starts to oscillate in ROLL and YAW when being in very thin air. :-/ Knocking the yaw & pitch scalar helps a bit but after a certain point control is just lost. It's so weird, without any help I can get the plane stable. There must be a way to tune PID properly! Should I increase the Kd value to dampen the oscillation? Any tips? :-/

[Crzyrndm]

There must be a way to tune PID properly!

Good news: There is.

Bad news: It's only really applicable for a relatively stable process. Flying aircraft isn't a stable process, especially with FAR.

Are we talking about Pilot Assistant or SAS here?

[Behemoth1702]

Good news: There is.

Bad news: It's only really applicable for a relatively stable process. Flying aircraft isn't a stable process, especially with FAR.

Are we talking about Pilot Assistant or SAS here?

Thanks for the reply!

Pilot Assistant. Haven't tried "SAS only" yet.

[Crzyrndm]

Sometimes, when I come out of pilot assist mode (which I mostly just use as a long-distance cruise control), pitch oscillations reoccur. It looks like the stock SAS PID tuner isn't taking effect when toggling the pilot assist features off. In the most recent flight, it kept oscillating until I reselected "control from here" on the cockpit. I have no idea why that worked, but it did; pitch wobbles instantly disappeared.

So far I'm unable to replicate this issue and I'm completely stumped as to what the cause could be. The display values are pulled straight from the Stock SAS module every draw call so in theory there is no way for the module to be out of synch with the window.

Pilot Assistant.

Oscillations in roll and yaw is the wierdest thing. Default settings has the yaw axis only acting as a damper (Bank => Yaw: 0,0,0.01) and most craft lack control authority on that axis so rapid oscillations are almost out of the question. That leaves undercompensation, where it doesn't try enough until the oscillations are already noticeably large. Increasing Kd should knock that on the head.

Roll issues are the opposite, most craft are relatively unstable in roll and have a very high apparent control authority on that axis. This often causes rapid jerky oscillations as the derivative action responds too hard. Decreasing Kd prevents it from overcompensating from these rapid changes and exacerbating the issue.

[Behemoth1702]

Oscillations in roll and yaw is the wierdest thing. Default settings has the yaw axis only acting as a damper (Bank => Yaw: 0,0,0.01) and most craft lack control authority on that axis so rapid oscillations are almost out of the question. That leaves undercompensation, where it doesn't try enough until the oscillations are already noticeably large. Increasing Kd should knock that on the head.

Roll issues are the opposite, most craft are relatively unstable in roll and have a very high apparent control authority on that axis. This often causes rapid jerky oscillations as the derivative action responds too hard. Decreasing Kd prevents it from overcompensating from these rapid changes and exacerbating the issue.

Thanks for the tips!

I should have explained better. Oscillations are veeery large and veeery slow. I will make a video in the new year to show it.

[Eddlm]

I found a problem. When you're using the pilot assistant, activate (normal) SAS and change your orientation/altitude, and disable SAS again, your the Pilot Assistant doesn't update its info about your heading and tries to handle the craft into the heading it had before activating SAS.

I have to deactivate both Pilot Assistant features (heading control and altitude control) and re-activate them so they update correctly.

I would love an simple "horizontal velocity" controller, too. I'm not too good at controlling at wich velocity my craft starts being unable to hold itself in the air, and being able to control it's velocity would help me a lot.

[Crzyrndm]

Thanks for the tips!

I should have explained better. Oscillations are veeery large and veeery slow. I will make a video in the new year to show it.

Large and slow means you need to increase proportional/derivative and/or decrease scalar. That only happens when it can't respond enough to correct until the error is really large.

I found a problem. When you're using the pilot assistant, activate (normal) SAS and change your orientation/altitude, and disable SAS again, your the Pilot Assistant doesn't update its info about your heading and tries to handle the craft into the heading it had before activating SAS.

I have to deactivate both Pilot Assistant features (heading control and altitude control) and re-activate them so they update correctly.

I would love an simple "horizontal velocity" controller, too. I'm not too good at controlling at wich velocity my craft starts being unable to hold itself in the air, and being able to control it's velocity would help me a lot.

Bug is being squished. Horizontal velocity control as in throttle? I'll think about it.

EDIT

v0.9.6.1 released

• Bug fixes for pause/unpause handling
  
• Prevented WASD inputs changing Pilot Assistant's targets while paused
  

Edited December 31, 2014 by Crzyrndm

[funk]

THX for update... this is one of the most useable mods for KSP I can think of... keep up the good work.

I've played a while with it, but there are two things I've recognized:

1. With vertical control target altitude is never reached and it starts to oscillate around 0 m/s vertical speed if you come close to target altitude... sometimes +-100 m/s. The craft seems to overcorrect pitch if nearby target altitude and needs some time to pitch up. Is there a hint I'm missing?

2. Target heading behaves like it should, but if you're flying over the poles it doesn't change heading +-180 degrees. So the plane is going to side-slip if you don't pay some attention to the 89th degree lat... This also applies to SSAS. Perhaps it is possible to implement some exception for transition.

Edit: For the professionals in this field: Why vertical velocity drops if entering physical warp? Is it FAR/DRE or KSP/Unity related?

Edited January 1, 2015 by funk

[Crzyrndm]

1. With vertical control target altitude is never reached and it starts to oscillate around 0 m/s vertical speed if you come close to target altitude... sometimes +-100 m/s. The craft seems to overcorrect pitch if nearby target altitude and needs some time to pitch up. Is there a hint I'm missing?

2. Target heading behaves like it should, but if you're flying over the poles it doesn't change heading +-180 degrees. So the plane is going to side-slip if you don't pay some attention to the 89th degree lat... This also applies to SSAS. Perhaps it is possible to implement some exception for transition.

1) Sounds like a tuning issue, probably an imbalanced Ki/Kp if it's oscillating as it leaves the clamps (which only happens as it approaches the target). What Kp/Ki/Kd/Scalar do you have on the vertical speed controller?

2) Bah, I keep forgetting to fix that. I'll go and do it right now...

Edited January 1, 2015 by Crzyrndm

[Hyomoto]

Alright, so after wanting to murder this system I finally figured out why it hated me so much. When you are tuning the altitude/velocity PIDs if you don't adjust the control surface angle of attack PID it doesn't matter what you do. Nothing I did seemed to have any impact on the oscillations coming off the elevator, I guess it makes sense it would be under control surfaces I guess.

Given the complexity of the system, the layout is far from ideal. The altitude and velocity PIDs don't really require much tuning craft to craft, but the AoA is clearly the bane of all existence and yet it's the one that gets hidden. Shouldn't it be the other way around? I got it working and I think I understand better how to deal with tuning issues in the future, but this mod got me really fired up. It might be nice to have a low profile mode. Once you've finished your tuning, you don't need much more than to input target altitude/speeds and heading/banks.

The system clearly requires quite precise tuning to get it work properly, something we just don't really have good tools for. The only way to test it is to throw your craft into the sky and see if you can tune it. I can't imagine working FAR that way. Some sort of 'simulation' would be nice so we could observe the oscillations in a more controlled environment. For example, fixing the oscillations in the elevators caused another interesting issue: the system is very slow to respond to small change and makes sweeping adjustments to get there. It's odd to put in a higher altitude and watch your craft nose down for a thousand feet before it decides it's going the wrong direction.

Edited January 1, 2015 by Hyomoto

[Crzyrndm]

v0.9.6.2 released

• Fix for erroneous heading behaviour around planetary poles.
  

Alright, so after wanting to murder this system I finally figured out why it hated me so much. When you are tuning the altitude/velocity PIDs if you don't adjust the control surface angle of attack PID it doesn't matter what you do.

It's hidden because I have exactly the opposite experience. I barely ever touch any of the 3 hidden controllers and even then it's normally just testing that they aren't the cause of w/e issue I'm having. VSpeed gets the majority of my attention, altitude gets it's Kp increased/decreased depending on how it approaches the target (overshoot = reduce, too slow = increase), the roll/yaw controllers I normally just tick back the scalar since their behaviour isn't particularly important so long as they're stable.

Edited January 2, 2015 by Crzyrndm

[Arthree]

Do you have any plans on integrating navigation to/from KSP or the science waypoints? Also, it would be awesome to have some kind of ILS hold for landing... maybe integrating with the NavUtilities ILS or something?

[Crzyrndm]

That would be a no on both counts. ILS stuff is already quite easy to do manually when combined with Nav Utilities (match sink rate and heading to appropriate Pilot Assistant functions, use fine control when required for tweaking), and actual navigation is well beyond scope.

[Behemoth1702]

Do you have any plans on integrating navigation to/from KSP or the science waypoints? Also, it would be awesome to have some kind of ILS hold for landing... maybe integrating with the NavUtilities ILS or something?

Check out "Kerbal Flight Indicators". The little yellow circle represents your velocity vector. Put it on the end of the runway. Could not be any easier for mod creator and user to have a kind-of-ILS system combined with pilot assistant.

[MasseFlieger]

Hi Crzyrndm,

Have you thought of adding some props for IVA use?

I would love to have altitude, heading and speed available through a set of knobs with a digital display, much like a typical airliner autopilot panel?

Either way this is a great mod! Part of my install list!

[Behemoth1702]

Look for SteamGauges.

PilotAssistant is not really about UI, it's about controlling a vehicle.

@PID Controller information, maybe include this into your opening post, so that people have some ressources when they want to tune them.

Overview:

Examples:

I learned a lot.

Edited January 3, 2015 by Behemoth1702

[Crzyrndm]

Have you thought of adding some props for IVA use?

(Atleast) Two reasons that won't happen

1) As behemoth says, not in mod scope

2) I can't model at all

Look for SteamGauges.

PilotAssistant is not really about UI, it's about controlling a vehicle.

@PID Controller information, maybe include this into your opening post, so that people have some ressources when they want to tune them.

Overview:

Examples:

I learned a lot.

You don't have a problem with the use of Laplace representations (all the equations using 's')? The actual explanations are very good, but I wonder if people would have problems with that representation

[Behemoth1702]

Oh dude, the math goes over my head big time, school is a few years ago and I never had this kind of math.

All I mean is:

I learned how to manipulate the values in order to get certain effects. With some fantasy you can clearly see how it works in KSP and how to manipulate it.

The only thing I still have to figure out scalar/clamp.

Let's say the error is 1.

Kp is 1

Ki is 0

Kd is 0

Scalar is 1.

Is this going to produe a signal of "correct value = 1"?

If scalar 2 is used, is it going to produce "correction value = 2"?

And scalar 3 further increase the multiplikators?

Thanks in advance.

[Crzyrndm]

Oh dude, the math goes over my head big time, school is a few years ago and I never had this kind of math.

That's fair enough. Laplace transforms were a part of my second year of University IIRC.

Let's say the error is 1.

Kp is 1

Ki is 0

Kd is 0

Scalar is 1.

Is this going to produe a signal of "correct value = 1"?

e = 1
response = { Kp * e + Ki * sumOf(e) + kd * (e - prev_e) } / scalar
// simplify and substitute
response = { 1 * 1 + 0 + 0 } / 1
response = 1

So yes, an output of 1 would result

If scalar 2 is used, is it going to produce "correction value = 2"?

And scalar 3 further increase the multiplikators?

It's a divisor rather than a multiplier (as you can see above) for consistency with the stock SAS. I probably should have inverted it for display but what's done is done.

As far as the clamps are concerned, response gets passed through this check before being used (output clamp)

if (response > upper_limit)
   response = upper_limit
else if (response < lower_limit)
   response = lower_limit

and when doing the summing for the integral, that sum is also passed through the same check before being used to calculate the overall response.

Make a copy of this and you can examine how they all interact (although, it would be easier to make graphs rather than stare at numbers directly...). You can see what happens when the derivative is too high (look for a very bouncy response), how the integral ends up being the only operative term, why the integral clamp is required (set the setpoint really high and the I_clamp to a -ve value), etc.

Edited January 4, 2015 by Crzyrndm

[steve_v]

Cheers for the handy explanation, I was thinking the 'scalar' might be er.. backwards, hence I haven't been using it

Was about to ask, but beaten to the punch

[Crzyrndm]

Cheers for the handy explanation, I was thinking the 'scalar' might be er.. backwards, hence I haven't been using it

Was about to ask, but beaten to the punch

Use the scalar to compensate for changes in dynamic pressure (proportional to: pressure * velocity ^ 2). For the most part, once you have a reasonably stable tuning (Kp/i/d) the only major difference is the amount of control authority your craft has (which corresponds relatively directly to dynamic pressure). The exception is transonic regime in FAR, but since it's temporary, changing scalar is also the appropriate response (unless ofcourse your plane only flies at Mach 1)

It's not a linear relationship though (hence why I haven't got anything happening automatically), so only adjust as needed (and remember to decrease as you slow back down as well)