Like many teams we are considering a “pitching machine” type of shooting mechanism. The idea would be to use a motor driven wheel with an encoder on it and control the RPM via code to ensure consistent shooting.
The question is: should we use PID to control the RPM or just do a lookup table and some basic checks for RPM and time. This is a bit of an argument between myself and another mentor. The students arn’t yet to this point so we are trying to educate ourselves so we can give them good advice for things to look into.
Personally, I’m heavily in favor of using PID so we can “close the loop” on the RPM and really control it. One of the other mentors is suggesting a simple look-up table as the good simple approach and I want to know if I’m overcomplicating this or not. I usually am, so I figured I’d ask you experts. I get beat up a lot on the whole KISS principle on the team so I figured I’d ask here. I’m almost always going to suggest we do what the real-world industry does when there is a question and sometimes that leads to more complex things than people want, for better or for worse.
One concern I have with not using PID, even if the system is simple, is that PID accounts automatically for the unknown. If we say a motor setting of 10 = 500 RPM and that’s it, how long do we wait to reach 500 RPM? It seems we’d need to get the RPM checked frequently and when it hits 500 RPM we are ready to shoot. But that means if the battery is under more or less load and/or drained more at the end of the match the RPM might be missed, might take longer, might fluctuate, etc. So now we add in an error rate to account for variability in the RPM due to outside influences. Wait a minute - arn’t we now starting down the path of making a bad version of PID?
In my mind, PID doesn’t remove these problems, but it can handle them automatically. We take the RPM and compare it to the error rate and when tuned properly we should be able to hold a good RPM with minor fluctuations consistently. When error rate is low enough - shoot. PID also lets us change RPM quickly by overshooting and then correcting down. This is faster than a simple 10 = 500, 20 = 1000. PID might shoot to 40-50 to get closer to 1000 and then back it off fast. Again, tuning is key with all of this and while tuning is a pain in the rear this is a reasonably simple tuning all told.
So, am I off my rocker? Over thinking the problem? Thanks!
-Mike
-=-
PS: To make this post useful for others and try and pay back the community for all my dumb questions, here is a very good PID library written for the Arduino and likely easily ported to the cRio (not positive of this, I’ve not dug into the code much):
http://arduino.cc/playground/Code/PIDLibrary
And here is a superb series of blog posts for this library and how he handles many of the problems with basic PID control:
http://brettbeauregard.com/blog/2011/04/improving-the-beginners-pid-introduction/
And finally, here is a detailed write-up based on that same code but ported to mbed. This write up shows the details of using it to control velocity and tuning it:
http://mbed.org/cookbook/PID
That last write up shows a good “moderate” tuning for their application but if they were to switch tunings from moderate to aggressive when the differential was high they could actually get a better response. Not really sure why they didn’t use all their derived tunings for more responsiveness and better holding but switching tunings based on the change needed is a great trick and a good optimization once you get the base-tuning dialed in. The Arduino examples show this.