Quote:
Originally Posted by Iaquinto.Joe
The NI PID provided does not work with rates, only distances. Because you are measuring a rate, the PID behaves differently.
|
Where did you get this idea? The
PID VI is entirely
mathematical - it doesn't care what the inputs are, all it does it brings the error of the system (Setpoint - Process Variable) down to zero. It will work exactly the same with encoder rates and distances, provided that the SP and PV are scaled the same way (and the constants are tuned properly). I'd be more than happy to explain how some of the math works, if you'd like.
As for your specific system issues, it just looks like the constants aren't tuned properly. Read a little bit about
PID Theory (also:
wikipedia) and take a look at some
tips on designing a good controller (the rest of that page is helpful too). You may also want to start with the
Ziegler-Nichols method for tuning (start with all zero, bring P up until it oscillates, add D to dampen and add I to correct for steady state error.
Just another note - if I remember, the LabVIEW implementation of the algorithm doesn't use Kp, Ki, and Kd as straight constants. It actually uses
time constants for I and D (so it has Kp, Ti, and Td). You can see
details of the NI implementation
here. You can verify this in the help popup (ctrl-H) for the VI. Plan your constants accordingly.
Quote:
Originally Posted by Iaquinto.Joe
Additionally, the EncoderOpen.vi distance per tick should be calculated based off your encoder ticks/rotation divided by the circumference of your wheel.
|
You do need to do this though - remember what I said above about proper scaling? That will put the output of the Distance from your encoder Get to be in realistic units (depending on how you scale it).
Also, what is that .02 constant doing? Is it wired to dt? You can delete that - the PID VI will calculate it for you if unwired.