[lorem3k]

Originally Posted by galewind

We had a sample program that we used to test the the adjustable PID values and the results, to verify what we would need so that our shooter wheels stayed within the desired RPM values that we set it to (or based on distance to camera targets). It took us a couple of hours and bit of network searching to find acceptable values for the variables, but once we did, it was set and we never had to deal with it again.

Over the course of our competitions, we did run into some reported "time-out" errors on our CAN network, according to our driver station output log, but they were so intermittent and quickly resolved so they never impacted the way that our shooter functioned. We stuck with it and were happy with the performance and advantages we gained by using it. (we used it so that our upper elevator section would not move to feed balls into the shooter unless we were able to determine that the wheels were moving at the desired RPM)

I would say don't dismiss the idea without experimenting -- it can be a great asset when trying to maintain something like a shooter wheel speed -- but it is not a simple plug-in-and-go solution. Like most new technologies, it will take time to learn how to configure and adjust it... but it definitely has advantages.

I will consider experimenting with the CAN bus during build season if there is some extra time available, but until I'm confident with using it, the Jags on the robot itself will probably continue using the PWM interface we already know.

Originally Posted by Ether

For shooter wheel speed control, consider using this instead of PID.

Thanks for the link. I will give this a try if next year's game involves a shooter or another mechanism that requires wheels to spin at a constant speed the entire time.