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) T ** his is standard practice in PID
system s (and defiantly in any aircraft AP Pid)**
Is there any chance this request can be given some consideration. Currently,
the AP system can get into a mode where the Integal rises to such a high
value, that if the AP is later switched on, the PID cannot come out of limit,
and this results in the AP driving the plane to an unusual attitude, with
resulting disaster. What is need is either the AP is programmed to clear the
Integral, when turned off, or some Event added, where the AP Integral can be
cleared programmatically. The first option would appear to be the easiest to
implement, and the most foolproof, as it would clear the AP Integral
automatically. In an idea world, there would be an AP API, with full exposure
to the internals of the AP Pids
This! it goes like a rocket up or down!. I second this request please. Many
thanks. Raul
Hello @N6722C There is many different PIDs in the AP
system. Some require the integral to be set to zero; some don’t. In theory
this is managed correctly, but depending on the aircraft, and AP mode, there
may be issues. The problem occurs when a PID is being computed while not
having an effective action, this will cause the integral to drift. We have
fixed a few ones already but maybe not all. Do you have a precise example of
which PID requires an integral reset, for which aircraft and in which
situation? 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? Regards, Sylvain
I have one that could be directly or indirectly related. We are trying to
transition fighters to FBW as part of AFCS. While with AP deactivated there
are no problems and it behaves as we want, when activating AP there is a
significant delay until it starts working. Suppose that after several
aerobatic maneuvers I decide to activate the AP and activate HDG, the plane
does not obey until after a few seconds, and when it does, the bank turn is
brutal. The same happens if you activate NAV. And the same thing happens if
you want to intercept star manually and then disable GPS DRIVES NAV1, and
activate AP + APPROACH for an ILS landing with a valid frequency, it doesn’t
always capture the GS and ignore it. That is, it effectively looks like a
saturation with AP + FBW, which does not occur if the aircraft is defined as
non-FBW in flightmodel.cfg (we have this behaviour in concorde often despite
not being a fighter). Likewise, having GPS disabled to capture a GS in VOR
mode does not always guarantee that the aircraft captures the GS or pursues an
LOC, it is as if GPS was still enabled (again this happens in concorde but is
also more noticeable with a fighter).
What I mean is that it feels like sometimes the autopilot operation or an
autopilot function doesn’t kick in instantly, sometimes it takes a while to
kick in, and sometimes it doesn’t kick in unless you move the plane manually
so that “something” internally “resets” and it happens more with FBW planes
than non FBW.
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 )
I am sure you have a valid issue, but I would be very surprised if it had
anything to do with this issue about zeroing the Integral error, when the AP
is in an Off state.
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)
Hello @N6722C 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.
I assume this is not going to be addressed in the near future, maybe not until
Asobo fills that AP Dev Position they have been advertising for, for ages. In
the meanwhile, as far as the SDK is concerned, you or your staff might want to
take another look at the whole PID section in the SDK, and reconsider a
complete re-write – it is just so far “Off the mark” and indicates a
disturbing misunderstanding of what a PID is, and how they work.
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).
Hello Can you elaborate on why or where you think the documentation is wrong
please?
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.
Thanks for asking, but I belive it to be so Basically wrong and off target,
that really it woud be easier to re-write it for you, that to try to break
down where it is wrong and misleading. Hopefully, .Asobo will be successful in
hiring an AP developer with Control Systems Engineering experience, who can do
a re-evaluation and re-write that section of the SDK. in house for you. It
won’t be a five minute “Edit”
Definitely not SU10. It’s just in the backlog for now, can’t give an ETA.