PID Control for Jaguars with PWM?

[lorem3k]

If you wish to use PID with US Digital encoders to control the speed of Jaguars for driving, do you need to use the CAN bus on the Jaguars, or will it work with PWM?

[Ether]

Originally Posted by lorem3k

If you wish to use PID with US Digital encoders to control the speed of Jaguars for driving, do you need to use the CAN bus on the Jaguars, or will it work with PWM?

If you want to use the Jag's built-in PID, you must use CAN.

If you use PWM, you can do the PID in the cRIO, either home-brew or WPILib.

[lorem3k]

Thanks. Is there any disadvantage to using the one on the cRIO? I know that CAN has its advantages, but our team is much more familiar with the PWM interface, and we already have all the resources required for it (namely, a whole boatload of cables).

Would the code for using the PID controller differ at all between the cRIO controller and the CAN Jag controller? Which one is handled by the WPILib/WPILibJ PIDController library?

[chris1592]

Originally Posted by lorem3k

Thanks. Is there any disadvantage to using the one on the cRIO? I know that CAN has its advantages, but our team is much more familiar with the PWM interface, and we already have all the resources required for it (namely, a whole boatload of cables).

Would the code for using the PID controller differ at all between the cRIO controller and the CAN Jag controller? Which one is handled by the WPILib/WPILibJ PIDController library?

Our team used CAN with our encoder plugged directly into the Jag at our first competition and were disappointed with the results. Tuning the PID values was a lot easier when we ran PWM directly into the cRio.

[lorem3k]

Originally Posted by chris1592

Our team used CAN with our encoder plugged directly into the Jag at our first competition and were disappointed with the results. Tuning the PID values was a lot easier when we ran PWM directly into the cRio.

If that's the case, I think I'll stick with PWM and use the cRIO's controller, having never used PID before.

[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.

[Ether]

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.

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.

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

[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.

[DonRotolo]

The advantage of using the Jaguar's internal PID control loop is that the cRio does not use any CPU time for that task. Very valuable if you have a lot of PID loops or your cRio is seeing heavy utilization (e.g., over 60% CPU load). The disadvantage is that you must use the CAN interface. While not terribly difficult, unfamiliar territory in the middle of the season might be best avoided.

Running a PID loop on the cRio is slightly more effort, but PWM control should be very comfortable by now. There is a library function for this (at least in Labview), or you can write your own.

I advise building a special program that runs just this code and nothing else, so you can get familiar with it and tune it without worrying about drive/dashboard/etc. code.