I’ll bite. I am no expert and only have an understanding about PIDs from
I kind of understand what Asobo are trying to get across, but their example of a car cruise control does not apply to an aircraft aileron and elevator control. But maybe ok for autothrottle.
In a car cruise control you have zero input (error between wanted and current speed) to produce a constant output of the gas pedal that is non-zero.
In an aircraft you want the output to be zero with the input zero. You want the elevator and or ailerons to be neutral (zero output).
I can follow their explanation and don’t see anything that would be an issue. So what are you seeing?
Thanks for your input … but to save unnecessary confusion, and long complex technical explanations in this thread, of what may be wrong (is wrong to be blunt), that’s why I really addresses this question to those who are more highly knowledgeable about PIDS, who should be able to see very clearly the issues.
I don’t see an issue with the highlighted passage.
In general, a proportional only controller will have a tendency to have an error term that never quite goes away, due to the tendency the passage is referring to. Only when the plane is perfectly in trim do you want a zero output from a zero error, for example, when writing a pitch control loop. And that’s a very rare scenario to be in exact trim like that. In fact, generally the trim control loop is driven by feedforward from the elevator position, to cause it to drive to zero. But you need to hold it with some output until then to keep the elevator into the airstream.
Now, in software, of course, you can use a P only controller to solely add or subtract from the output depending on the error, and then the next cycle starts with that output value and adds and subtracts from there. In that case things are a bit different. But as a very general PID article I’m not spotting anything I haven’t read in a hundred other PID papers.
Additionally, I don’t tend to start with the I term myself when tuning, but that is a very commonly used technique, especially in industrial control loops, where you very often need the output to hold some voltage constant at where the integral climbed to after reaching 0 error (holding a valve actuator open for example).
If both Asobo & WT are happy with the SDK description and the way that the MSDS 2020 PIDs are working, then I will accept that I do not have the necessary technical knowledge to understands this, and will stop raising this as my perceived issue — (at least till until someone else brings it up again)
I should probably read some more Pid papers, because you sure have me beat at 100 !!
Thank you for bringing this topic to our attention
I think first of pid for it stand of what i belief as perphal input device and i should give and identifier to all periphal device in combination with the usbport used for the device.
i do not know for sure if it is a bug but for what i know since windows7 is that if i put my logitech (former madcatz) ap and com panels in the usb it strained to a certain pid and migration state which links the port, periphal and vendor in one id, but since windows7 if you choose different usbport it states has not migrate due to partitial or ambigous match.
Now this next photo’s are an example from my drawing tablet
What to do, i do not know (please chime in if you know anyone) but since it is in regedit i leave it for it works fine although i see it as an inconsistancy.
But im curious now
I think with arduino it might be interesting for motorized quadrants and to see the movements in AP gets automated as for real.
Well - you could try editing your title to perhaps read “PID Control in Autopilot for MSFS” - and the technically knowledgable readers you’re trying to reach would get it right away.
So far, this is what i understand and interpretate on this subject.
If in the car on cruise control you have zero input, this is on a flat road i suppose but if draw the line further, let say the road get a lets say 3 % of incline than the numbers of proportional and derivative factor comes in to maintain zero. I t must work to keep the desired speed.
If not on cruisespeed to maintain say 60mph going up the hill you must apply pressure on the gas in a proportail way to accelerate. If given to much pressure it needs to derivate like release pressure to re-find the desired speed to much out of control eitherway means overshoot which means imo causes lags or stutter because the reaction time of the computer is to slow and i loses track.
So all these pidparameters are need to carefully be calculated because one affects the other to keep on track.
The car is just a simple example because more people are familiar with driving and not so many people have flown themselves in real life,
But than it has to be computed and within the limitations of the sim.
The more I read and re-read the PID primer the more I agree with the OP. This needs to be rewritten, with aircraft analogies. If you are an aircraft developer - you better understand how an aircraft flies.
It needs work on the zero input explanation. It confuses me. But again I admit I really am no expert.
I may be wrong or maybe going off topic later on, has to do with the way my mind works, sorry for this if blurry, but the way im thinking and quess, When it is all about input compare to movement and factors like weight, lift ballance, wind etc. I think these are very much about trim controls of ailerion, rudder and pitch speed etc but you get that already from the pidprimer file.
But i also think it has to do with the in sim behavior of calculations of factors of what shows up i on screen and that relation the i see it is pid in is own way.
I mean with well trimmed conditions on periphals like the yoke in ui we can tune i find
It smooths the sim give some sidewind and the focus on runway get wonky maybe translated in overshoot of Error to high or low that is where trail and error comes from.
But even this Video, as good as it is, really does not come close to addressing the factors involved in an aircraft AP PID..
Surely, we have some Control Systems Engineers or Aeronautical Engineers in our Forum Community , who could supply some more relevant input. ?
For those interested, and wanting a deeper understanding, the following part, of a multipart Video series, is one of the best ones I have so far found on Youtube … but none directly deal with the Aviation applications of PIDS.
Warning: Maybe not the best 1st PID video to try to watch and understand !!
When the game came out the autopilot was perfect. On my mods i used mainly Proportional control and 0 Integral. It worked perfectly. No overshooting, no wind up.
I dont understand what flight simmers expect from autopilots. If you’ve ever flown an autopilot in a GA plane you know they are clunky and will kill you if you look away. They rock back and forth and will easily drift 200 feet if the air is convective or during speed and configuration changes. Its then your job to disconnect and fix the situation. And im not talking about some old KAP140, im talking about the new Garmin stuff.
Plane autopilots aren’t even PID controllers in pitch, they are more or less click clack. The elevator trim does not move smoothly, it ticks up and down, like using the trim switch (because thats basically what its doing). The trim stays where it was an basically gives you your Integral. Aileron is a weird middle ground. It kinda taps it self over to one side till the bank is recognised, reached, and tries to hold it.
The main problem this game has is the integral wind up, and the fact that it doesn’t reset when the autopilot is turned off. That would fix 90% of the problems that we have. The other 10% would just to correct the logic when it came to intercepting and constant rate turns etc, but i think WT is working on that.
AT LAST – some who know what they are talking about (ie agrees with me )
I have been trying to get Asobo to recognize this and zero the Integral error when the AP is turned off for over a year … with no success.
Even tried the WT approach, without any success.
The SDK description in this area really is not helping, but I am told it is correct …
Hopefully someone else can do better than me !!
The Frustration is that actually coding the AP to clear the Integral when it is turned off, is so trivial… especially compared with convincing Asobo to do it … as Devs cannot do it, as that internal variables (ie PID Integral error) of the AP Pids are not exposed to them.
Duhhh … I did not even think of your most Obvious work around … ZERO INTEGRAL error in the PID config… not ideal, but a better alternative to Integral Windup !!
For those that can’t find the info on this, it’s in an earlier version of the SDK release notes. 0.20.1
NEW! The [AUTOPILOT] section of the systems.cfg file has the following new PID parameters documented: pitch_pid_reset_mode, pitch_pid_max_I_accumulation, roll_pid_reset_mode, roll_pid_max_I_accumulation, heading_pid_reset_mode, heading_pid_max_I_accumulation.
OT
It’s just out of curiosity:
Does one really need control theory to simulate an autopilot in a sim ?
In msfs you obviously need it.
But if I had to programm a sim, I would just let all disturbances as input values to the plane model be zero, and easily program the perfect flight path. As disturbances I would take stick and rudder input variables. Of course that would be a fake, but it’s a sim that’s not used for certification of an autopilot system after all. I would not model an autopilot stand alone model
)