Implementation of Velocity Control Algorithm Based on PID

Question

I'm very familiar with the traditional position form of PID. The error is just the difference between some setpoint encoder value and the current encoder value. Although this suffices for basic autonomous routines, it would definitely be more powerful to control the motors' velocities. Thus I'm here now trying to implement velocity PID.

Error is probably going to be the difference between some desired encoder value change over time and the current change of encoder values over some known time. However, as the motor reaches that desired velocity, the error goes down (who would've thought), but because the output is proportional to the error (again, who would've thought), the motors logically begin to slow down. That's one problem, the motors have to keep up their outputs to stay at a velocity, not slow down as they get closer.

My first idea was to implement some kind of feedforward to estimate the velocity then let I and D do the rest of the work to get the motors at the exact desired velocity. But is that really industry standard or something, like I would be eliminating P.

Another idea was to take the derivative of the position form of PID (found it at this site: https://www.controleng.com/articles/the-velocity-of-pid/)

I've tried looking for alternatives to these two methods (my possibly very jank way and the probably more formal and accepted way). And oh god, I still have filtering sensor data to think about.

So my question:

How do I implement velocity PID in order to control my motors' velocity? Which algorithm should I use?

Answer 1

Why does the PID algorithm need to be different? You're basically describing robot cruise control. Your setpoint is your desired speed, your input is your current speed, and your output is an accelerator value ("throttle")

Your comment about motors keeping their outputs up to stay at velocity is really a conversation about how much overshoot you want -- you want to accelerate at some non-zero rate to achieve your target velocity, and then slow down your acceleration as you approach it.

The beauty of the PID is that it doesn't actually care about the system it's controlling - it just needs the input, the error and a single control value to adjust the input. You have all of those.

... Unless I'm massively missing something, which is possible.

Answer 2

When you have an encoder with sufficient resolution, you can just take the first difference (to get a velocity measurement), and then use a PI or PID controller for velocity.

In my experience, because you're basically taking the derivative before you wrap the thing with control, just a PI controller will be plenty. The only exception to this would be if you're driving something that's got complicated dynamics (and then things may get weird, because you'd essentially be taking the derivative twice).

Answer 3

but because the output is proportional to the error (again, who would've thought), the motors logically begin to slow down. That's one problem, the motors have to keep up their outputs to stay at a velocity, not slow down as they get closer.

Theoretically and practically, even for simple systems, the error never really is exactly zero at all times, for nonzero setpoint.

If you are using a PID controller (not just P controller), then even if error $e = 0$ the other terms may be nonzero: $\int e \neq 0 $ or $\frac{d}{dt}e \neq 0$.

If all the PID terms become zero, the input to the motor will be zero and the velocity will drop. But as soon as it deviates from the setpoint, the error becomes nonzero, and the PID will again come into action. There is some delay between the error computation and the output of the system. So error won't be zero at all times.

You can implement the PID controller as usual. Tune it such that the error minimizes. You can plot the setpoint velocity and the motor velocity to see the controller performance.