For the past 2 years, our team has used PID through the CAN jaguar set PID functions. However, in light of multiple failures in the CAN jaguar system on our robot this year, including 2 jags suddenly failing to communicate with the bus in the Curie semifinals, we have decided to look into using talons as our primary motor controllers going forward. I would appreciate if anyone could post functional LabVIEW code to run PID for a shooter or similar application through the digital breakout, as my past attempts to do so have not been fruitful.
Can you provide more detail about what you mean by “not fruitful”?
Did you use the PID vi provided in the FRC LabVIEW installation, or did you try to brew your own?
Are you bound and determined to use PID for shooter wheel speed control? Many teams have been quite successful using simpler control algorithms such as bang-bang.
Have you tried searching the forums and reading some of the many threads on this topic?
We have used a PID function for the last couple of years in LabVIEW with very good success. Our entire source code project is available for download at http://www.trucktownthunder.com/resources.html. There is both 2012 and 2013 Dashboard and Robot Code available for download.
Within the 2013 code look at the ShooterControlLoop.vi in the Shooter Library\ShooterLibrary.lvlib. Most variables for tuning the PID loop are set in the T3-Prefs.ini which is read in Begin.vi.
Keep in mind that particular code implementations and their effectiveness are greatly dependent on the particular sensor characteristics and sensor methods employed.
1)I have yet to successfully regulate any robot functions using the built in LabVIEW PID tools
I used the PID.vi in the default toolkit
PID is the only method that I have interacted with, but I am open to other methods.
Yes, I have. Quite extensively, actually. Otherwise I wouldn’t have started a thread. I needed an example of implementation of PID in robot code through the DIO; It is not the theory behind it that is posing an issue. I am capable of using Google, but a search engine is only germane if the query is capable of finding the resource needed. If appropriate resources cannot be found in existing resources, then posing a thread in an attempt to better understand an issue is pertinent. As such, given the lack of specific examples that I found on the forums, I decided it would be best to attempt to find the answers by means of a new thread.
I remember our software team made a “teach-able” ARM and WRIST on our 2011 robot. You would jog the robot to a position, then rotate a KEY that was the “teach mode”. Then you pressed the button you wanted to assign those values too. And the crio wrote to a txt file the pre-sets.
Then the pre-sets where loaded into the Labview PID. It wasn’t very accurate, but it worked good enough to place tubes on a pipe.
*@David(blackflame2996): Did you get all your questions answered? Are your LabVIEW efforts fruitful now?
As efoote868 and Mark mentioned in previous posts, the controller is only half of the equation. The plant is the other half. If you find yourself still struggling, a give-and-take dialog here with more detail will allow us to help you (if you want).
We’ve had pretty good success with code similar to this code for the past 2 years with shooters. We were able to get fast spin up times with minor oscillation around the set point with little tuning at all. In 2012 we used a KOP encoder, this year we used a lower count US digital encoder both with good success.
LabVIEW (like other programming languages I would assume) you need to setup how many counts to average over, etc. to get the best results. I can’t remember off the top of my head how many counts we average over for the 64 count encoder.
As Ether said the Bang-Bang controller is also a really good option. I tinkered with it a little and it seemed pretty simple to implement.
