Time component for outputRampRate

[zhivko]

Nice project congratulation!
I would expect to be possible to acknowledge time component for outputRampRate. Now everything is cpu speed dependent - so if you can include time component - one could be sure that effect of same ramp rate limit will be on fast and slow mcus - theoretically...

So if possible it would be great if you could add dependence to time in uSec (getMicros()).

[tekdemo]

I don't think the CPU speed is super important. When running a PID, the important detail isn't raw speed, but consistency. Running at shorter delays has some utility in certain cases, but most systems don't care if they're driven at 4ms, 40ms, or sometimes even 4s. However PIDs are not tolerant of big swings in execution time on the same system (known as jitter).

For Arduino code, an optimal method is that seen in the BlinkWithoutDelay example sketch. This lets you call the PID functions at set intervals, regardless of CPU speed. Once called at a fixed interval, a given CPU will complete the PID operations in the same amount of time, achieving consistency.

If you're not calling it at constant time intervals, a lot of nasty variables sneak in and cause problems. This applies not just to outpurRampRate, but also the I and D terms. If you're using a delay(millis) method of time keeping, you'll see this a lot, as the Arduino framework does not inherently operate on strict timing. Not only will most general code have inconsistent run time, the Arduino framework will do background stuff at random times, making loop cycles inconsistently timed.

Later this year I do plan on adding improved time handling in the math. I've discovered that in one of my main use cases, there's enough jitter in the timekeeping framework that I'm getting really nasty values of 2-3x my expected loop time, and it's causing problems.

I won't be adding any Arduino dependencies though. While I personally use this library for Arduino projects, I feel it's more valuable to keep it dependency free for use in other systems (especially since I maintain a twin version in Java). So, the time component will be implemented such that you provide 2 parameters, which is all that's needed to handle this:

• The expected time loop (or 1 for a non-time dependent system)
• The current time or time delta from the last update (or, default to 1 if you don't use time).

The hard part is doing it without a bunch of floating point division, which is ridiculously slow and nondeterministic on systems without hard floating point cores (eg, arduino). As a PID needs to be fast and deterministic, I've strenuously avoided this operation in the main loop. I also would like to leave it operating without a strict time dependence, as much of the time the systems I work don't require this level of precision, and it would just muck up the code.

[zhivko]

I am using esp32 arduino (esp32 itself having 32bit floating point unit ) and I can call it via rtos task that is causing fairly precise timing.