Closed AlexT-38 closed 1 year ago
AlexT-38
commented
1 year ago PID was being given rpm_last_tick_time_ms as feedback, but this is a timestamp, not an interval between ticks.
RPM counter now has total time and total ticks (since last pid), calculates the average each pid update and uses that as feedback.
AlexT-38
commented
1 year ago PID's invert flag was set by a static initialiser, which was not updated after adding extra fields into the struct. Thus, the flag was not set correctly.
PID is now initialised explicitly, and there is a button on the config screen to toggle the invert flag. The default is inverted, which is correct for this setup.
The flag is not currently stored in eeprom, and should need to be changed for this rpm PID, which uses rotation time as feedback, rather than angular velocity.
AlexT-38
commented
1 year ago When RPM is low, RPM counter ticks may not occur within the PID update interval.
Previously, when RPM pid was interval based, the interval was increased by the PID interval.
Currently the RPM is exponentially decayed. However, this is resulting in an excessive drop in RPM observed by the PID, which can result in erratic output. Decaying the RPM by increasing interval time is more computationally expensive.
Either a better method is required, or the decay rate should be reduced.
Problem
Today's experiment with the pid controller for rpm did not go well. The output quickly saturated to full open, regardless of input setting. This occurred even with the "i" and "d" parameters zeroed.
Related issues
Version 3 log output doesn't currently show PID or servo outputs. Issue #14 ideally needs to be completed to solve this issue.
Test equipment
A way of testing the PID control without needing an actual engine would be handy. Perhaps connect a DC motor and ESC to the throttle output, and use an opto-interrupter for feedback. Alternatively, an UNO or NANO wired to receive servo signals, and programmed to simulate a motor and flywheel. Whichever is the least effort.