Welcome to
Microsoft Flight Simulator’s SDK Q&A Platform!
Please take a moment to read the platform’s guidelines before you get started!
Currently, when the AP is turned off, any accumulated Integrated Errors remain in the AP Pid, and take effect when the AP is next turned on, (often with disastrous effects on the plane's flight)
Since Devs do not have access to these internal values, to do it ourselves, please will Asobo code to reset ALL integral values within the AP Pids to zero, when the AP is in the OFF state . (or when power is not applied)
This is standard practice in PID systems (and defiantly in any aircraft AP Pid)
One good example is the KAP140 AP, as used in many GA planes.
If one picks a non DRM plane (ie jt the c172 Steam), , one can see the AP pids display in the Dev Console.
The issue is that on both the Pitch & Bank Pids, if the AP is run where it accumulates error, ie On the Ground ( say during an On Ground AP test), you can clearly see that the Integral builds up to a max limit, but thereafter, can never be reduced, even if the AP is attemped to be driven in the reverse direction. Even if the AP is switched off, (either turned to OFF, or its Power removed), that limited Integral value is stuck at a limited max value, so when the AP is next turned on, it drives the servo to limit, with no possibility of recovery (Unless the plane is re-loaded).
If the AP is turned off, and then later turned on, any Historical Intergrated Error in the AP is historic, and no longer relevant, therefore the AP should initialize to Zero Integral value, and from there, if appropriate, start accumulating Integrated error,
What is also strange, is how once that Integral has built up to 100% (as shown in the Dev Console), it is virtually impossible to drive it back from than limited state, no matter what Input is presented to the PID.
I cannot picture any AP Pid, not being required to reset, and zero it integral accumulated value, when it is turned off, and the current conditions where it drives to limit and stay there, and therfore will always result in not being able to use the AP again, (without a reload)., or the result will be an AP that always forces the plane into an unusual attitude.
In answer to your question,my question would be --- Is there ever a reason or justification why you would NOT want the Integrated error l to be zeroed, when the AP is turned off, so it starts off with zero Integrated error ?
As an example of PID integral we don't want to reset to 0, there's the pitch hold one. If we reset the integral to 0 every time it's switched on and off, this would cause oscillation instead of a smooth transition. Do you agree on that?
I don't think I agree, as I really do not understand where "oscillation" can come from" in that example. I would say, that the Pitch Integral SHOULD be set to zero, if the AP is turned off, so when turned back on again, the INITIAL integrated error is zero.
Note: The KAP140 is meant to Capture the current VS, when turned on.
The systems.cfg "Default_Pitch_Mode" ( 0, 1 ,2 or 3) will determine what the Pitch mode is when the AP is turned on. For the KAP140, it should be set to 3=VS mode -- ie captures current VS, but most devs are setting it to 0, so it always tries to set the VS to ZERO, when the AP is turned on, (which is incorrect for the KAP140).
Even worse, when set to 0, if the AP is turned off with a VS set, when it is next turned on, it will initialize to that old VS !!! This is not the correct operation for the KAP140.
So, if one has VS when turning on the AP, the AP will try to force the plane to zero VS, and that may well cause some oscillation, if the PID is not tuned correctly (which so many devs fail to do).
In answer to your question then, (for the KAP140),
(a) "Default_Pitch_Mode" should be set to 3
(b) Accumulated Integrated error should be set to zero, when the AP is OFF, so when turned on,the AP initially has ZERO Integrated error.
Note: It would be MORE CORRECT if the C172 Steam (Premium -Deluxe) DRM encode plane could have its "Default_Pitch_Mode" set to 3 - but as its encoded, this again, only Asobo can do that, (unless users creates and introduces a MOD file copy of systems.cfg )
The devs are having a look at your answer so I'll come back later with a better feedback.
In the meantime, here's what work is planned at the moment on the PIDs:
- Go through all PIDs (most are legacy) and replace them with new ones that are "correcly plugged". (Optional for retro compatibility of cours).
- Add a new integral limit to the PID system in a way that makes it actually useful.
- Give the option to "run PIDs in the background" or to "warmup" PIDs to avoid oscillation when they are "switched ON". Option to reset to zero can also be added as some real world AP systems may actually reset integrals to zero (completely agree with that).
FlyingRaccoon :
Option to reset to zero can also be added as some real world AP systems may actually reset integrals to zero (completely agree with that).
FANTASTIC !! The ability for the Developer to programmatically Clear (zero) the Pids (typically when the AP is turned off, ) --- is all that I was hoping for, and should eliminate the issues caused by both testing the AP on the Ground, as well as the AP sometimes getting locked up with Integral Runaway when in the air..
Hopefully this can occur on individual specified PIDs ..
Any Idea when we might see this in and update .. and in the SDK - Su10 maybe at least for the Integral Clear.
@
Have you and Asobo come around to the thinking that for the AP Pids, the Integral term should be zeroed, when the AP is turned off ...
If not, I have done a bad job in explaining and trying to convince you that this is required, and would like the opportunity to try to convince you
(Or have you, or someone else here, convince me otherwise)
The developer in charge of this is very busy at the moment so I didn't find the time to review your answers with him. Feel free to add any explanations you want :)
Thanks Sylvain ,
I appreciate that everyone at Asobo is very busy, and I thank you for the speedy reply.
The fact that you are going to discuss this with the relevant Developer is more than a sufficient reply.
I feel confident that when this is brought to their attention, they will address this issue in a satisfactory way.
Obviously, if they want more input from me, I can be contacted here...but I think the problem and its solution will be pretty clear to whoever has the design responsible for the Autopilot systems.
@FlyingRaccoon
Any progress with this, within the SU10 update period.
At he moment, is there ANY way a Dev can force the PID Integral error to zero ?
Its the height of frustration, to see those Integral Values displayed graphically in the "Aircraft-AP" Dev Mode screen, but not be able to access them or directly control them.
A thought:
Currently the PID values are constants in the .cfg file.
Some more advanced RL Autopilots will dynamically change those values, deepening on other criteria,
If those 5 PID values could be made read/writable, then a lot more could be accomplished to provide a close simulation of these more advanced Autopilots, and the ability to zero the Integral Error might even become a side effect of being able to control those 5 values Dynamically .
But at the moment, a great step forward would be just being able to programmatically ZERO that Integral Error :)
BIG THANKS to Asobo ( especialy @FlyingRaccoon ) for adding the option to RESET the Elevator & Aileron AP Pids in SU11
AP can now be "tested on the Ground" and now the AP cannot get locked up, and "crash the plane" when turned on, due to old Integrated data.
====================================
Do you have any news or updates on when "Battery Internal Resistance" will be added to the battery Simulation .When it brought up a few months ago, and you said it was "Planned", but no timescale yet . Hopefully it will be an A:var that is both Readable & Writable, so 3rd party Devs can make it vary as complexly as they want with Temperature, Charge level, Battery age, Battery type etc etc.
@N6722C As for the battery request, ping me in the dedicated post and I'll check if we have some news.
The request to add simulation of Battery Internal resistance was discussed in the following post.
At that time, (about 6 months ago) you said it was on the roadmap, but no ETA.
