PIDLoop parameters in SteeringManager:PITCHPID/YAWPID change inconsistently
quetschke opened this issue · 7 comments
I came across this when noticing that the time it takes to perform a 90 degree turn for the first time after loading into a vessel is different from the 2nd and following attempts. See the attached script used on a very simple vessel.
When executing the script for the first time (note, no parameters are changed, everything stays on the default values) the PID values for PITCH and YAW PID start with 1 0.1 0 directly after SteeringManager:RESETTODEFAULT() and end on 1 0.2 0 after the rotation has been performed and the change has settled. This takes 17.6s.
Running the script again a second time and every time thereafter the PITCH and YAW start with 1 0.1 0 and end on the same value and he turn takes 28.5s.
Another symptom:
Uncomment line 40 to 44 and set PITCHTS and YAWTS to 1/10 of the previous value. When executing this version for the first time after reloading the vessel you get the exact same values at in the above section. PITCH and YAW PID start with 1 0.1 0 and end on 1 0.2 0 after the rotation has been performed in ~17 seconds. Running it a second time the PID values end at 1 0.1 0 and the rotation takes 28 seconds.
Third case. Now uncomment lines 25 and 26 that set the I value for pitch and yaw. First run yaw: 1 0.4 0 and pitch 1 0.8 0, following runs: pitch and yaw will be 1 0.4 0.
There is a picture of the vessel attached. Nothing special, except the docking port offset to the side. I was testing something and I don't believe this is an issue.
Some observations in addition to the symptoms above:
- Setting PITCHTS and YAWTS does not change P and I consistent to what is written in the documentation.
- Initial runs (after loading a vessel) behave different than subsequent runs.
- P and I values change from before starting the turn to after even if PITCHTS/YAWTS are not changed.
This is kOS 1.3.2 - I have not updated yet.
If RCS is contributing to your control (and based on your screen shot it does) then in kOS versions prior to 1.4.0.0 we didn't know KSP did not tell kOS the correct torque you could get from RCS blocks. One of the fixes in kOS 1.4.0.0 is ignoring what KSP tells us for RCS torque and calculating it our selves. This inconsistent torque data if you are using RCS for rotation is likely the cause of the inconsistent amount of time it takes to rotate the craft.
As to the ROLLTS and YAWTS values those change the stage 2 PIDs not the stage 1 PIDs and only the stage 1 PIDs are exposed to the users thus the documentation remains correct.
My previous report was KSP 1.12.3 and kOS 1.3.2. I just updated to a clean install of KSP 1.12.5 and kOS 1.4.0 the only mod. The behavior stays mostly as previously described, except for the KI = 0.4 case with PITCHTS/YAWTS unchanged. I get more variations between tries. Sometimes the PITCH/YAW values stay at 1 0.4 0 or change to 1 0.2 0 / 1 0.8 0 in later runs.
As for your comment towards RCS, yes RCS is onboard, but the script has RCS OFF.
So, even if ROLLTS and YAWTS changes are not visible, the "stopping" times do not change. I get ~28s independent of setting ROLLTS/10 and YAWTS/10 or leaving them unchanged. Also, first run is (most of the time) different. Sorry, this is a bit nondeterministic.
Just to be sure, you are measuring time intervals in game time, not real time, correct? I only mention it because game time rate can change a bit over time if memory is tight as leaks and fragmentation increase
@darthgently the time is measured in gametime seconds (TIME:SECONDS) and I use a moving average over the sum of ANGLEERROR and ROLLERROR to avoid stopping early when crossing zero.
A PID loop in kOS can alter it's Ki if it has an extraUnwind flag set, I don't think this is exposed to normal users and is instead an internal thing for the steering manager so seeing the ki change is allowed. It should only be changing between 2x and normal. I wonder if the fact you are printing the Ki is causing issues with kOS changing the Ki and that is what is causing the accumulating values there.
As to determinism kOS tries but when KSP it's self is not deterministic there is only so much that can be done.
@nuggreat: I see changes in the Ki of either *2, *1 or /2. That's probably what you meant. So that part works as expected.
The ki should only be changing between a value of 0.1 and 0.2 (assuming default steering manager PID) the fact it isn't staying in that range and is going higher/lower means that some how the act of printing the ki is preventing the increase or reduction from taking effect some of the time is a problem.