@FlyingRaccoon Any progress in providing a way to ZERO the AP PID
Integrals , when the AP is turned OFF ? Either always by Asobo, or allowing
the Plane developers access to those Integral parameters, as readable/writable
Variables, or a Reset Event, that resets them all ? It is a continual source
of frustartion, that if the AP is turned on on the ground by the pilot (say on
a AP testing checklist), it drives the AP into an unrecoverable maxed out
limit state, with a “maxed out extremely high Integral Error”, that cannot be
reset, apart from by reloading the plane !! ( _ Adding “RELOAD THE
PLANE” at the end of the Checklist, is not a very good Solution 
_ ) I have
literally lost count of the number of times “MY AP has Crashed my Plane”
because of this and it should be such a simple, and NECESSARY fix, and
inclusion in the SDK.
@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
Disappointing to not seeing this PID Integral accumulation addressed in SU10.
At a Minimum, it would be useful to see a new K-event added, to clear PID
Integrals, with an index, for the various standard Asobo Pids. This would not
change the current operation of the Pids, (so would be 100% backward
compatible with all previous uses of the Pids), but would allow for Dev to
decide where and when they want to program a reset of the excessively built up
Integral. Ability to read and write those Indexed Integral values would be
even more flexible !!
honestly if we could just go back to the autopilot we had 2 years ago where
integral was not used id be happy. currently the only solution is to have such
a high Integral value that it acts like a proportional controller
Why is this being made so difficult ? The PIDs often need an Integral term, so
that should NOT be removed. What is required (as in any standard, Real World
PID) is (1) The Integral Error should have a controllable min/max limit
value (LIMITING) (2) The Integral Error should be reset to Zero, when the
PID s turned off. It’s really that simple. If Devs were given Read/write
access to that Integral error term, all could be resolved by the Devs who
chose to do so, and be 100% backward compatible with anything already
developed. Note: In an Ideal (Real ) World, the basic PID settings of
GAIN, Integral Gain & Proportional Gain would be made to allow their values
to be changed in real time , when the PID is running, to simulate the more
complex PID systems, used in modern aircraft control systems. (as opposed to
being Constants, set in a .cfg file) While open for a very long time,
hopefully the Position of “Autopilot Programmer” will be soon filled…
https://www.asobostudio.com/careers/autopilot-programmer-flight-sim-252
Going to BUMP this one again, this time with a positive SUGGESTION. Please
consider adding ONE new H Event Set_PID_Integral_Error:index, number Index
being defined as (say) 1: Pid AP Roll __ 2: PID AP Pitch 3: etc etc Typically,
one would call this event (for the AP), when the AP is turned on, or off,
setting any past accumuated Integral errorr to Zero, but it could also be used
to set the Integral value to some other value, say to simulate a fault in the
AP system, Gyro Topple etc etc. It would then be up to the Developer, if they
chose to call this event, and under what circumstances, the introduction of
this new H event, then being 100% back compatible with the current state
of MSFS. == Hopefully, sometime in the future, all the PID internals will be
made available in an full PID API, but in the meanwhile, just being able to
set the Integral Error Value (Typically to Zero it), will make the AP so
much more usable… ie AP Checklist testing when on the Ground The end to the
spiral of death, if the AP was earlier turned on when the Ground, and running
to an Integral limit.
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.
@FlyingRaccoon Thanks – Additions in SU11 are
perfect to Reset the AP PIDS …as needed …
A very good new addition indeed… thanks Asobo and team… Best, Raul
I’m just the messenger here but I’ll let our devs know the change was
appreciated. @N6722C As for the battery request,
ping me in the dedicated post and I’ll check if we have some news.
@FlyingRaccoon The request to add simulation
of Battery Internal resistance was discussed in the following post.
https://devsupport.flightsimulator.com/t/4013 At that time, (about 6 months
ago) you said it was on the roadmap, but no ETA.