Chief Delphi

Chief Delphi (http://www.chiefdelphi.com/forums/index.php)
-   Technical Discussion (http://www.chiefdelphi.com/forums/forumdisplay.php?f=22)
-   -   CAN mode question (http://www.chiefdelphi.com/forums/showthread.php?t=132252)

Ken Streeter 22-01-2015 15:17

Re: CAN mode question
 
Quote:

Originally Posted by Thad House (Post 1423859)
A Bang Bang Controller mode would be cool as well. I know the teams that used it in previous years, including us liked it alot. Would be cool having it just integrated into the controller.

I believe that you will get "Bang-Bang Controller" functionality from the built-in PIDF if you set Kp = infinity (just choose a really big number) and set Ki = Kd = Kf = 0. For "flywheel" applications, you'll also need to constrain the minimum output to be 0, so that when the flywheel is over the target speed, the controller doesn't "Bang" to maximum reverse.

In 2012, we used a bang-bang controller for our basketball-shooting flywheel. It worked pretty well. In 2013, we started out using a bang-bang controller for our full-court shooter -- it was pretty good, but not good enough for FCS. With experimentation during the 2013 season, we found that a PF controller (PIDF where I=D=0) worked more smoothly and more accurately. As mentioned above, PIDF with Kp=infinity and Ki = Kd = Kf = 0 degrades to bang-bang, so it's easy to test both alternatives by just varying the parameters while the robot is operating. For us in 2013, the improvements made the difference between FCS that nearly worked and actually did work. Retrofitting the improvements to our 2012 robot increased our accuracy shooting basketballs, too.

We're planning to use the Talon SRX this year with the built-in PIDF for most of our control loops. Haven't gotten them working yet, but that's been due to cabling issues, rather than problems with CAN or the Talon SRX.

ozrien 22-01-2015 18:42

Re: CAN mode question
 
[Rising Counter.]
If you use the Rising Counter/Encoder (EncRising) feedback device then the feedback device will only count in the positive direction which means the measured velocity will also be positive (or zero) and....

[Section 18 Closed loop code]
...additionally the oneDirOnly param will be true since EncRising is the "positive only sensor" mentioned in the function header comment. This is the only way to set oneDirOnly param. This will ensure that negative error (target speed < actual speed) doesn't output negative throttle (which is bad for a velocity control, we don't want to spin backwards!). I found that out the hard way when I tested velocity servo without it during development.

If you do want to do this be sure to note the part in Section 7.4 where you must set ReverseFeedBackSensor to false. Otherwise the PIDF will output negative throttle and oneDirOnly will clamp it to zero. If your motor and sensor is out-of-phase this is a good place to use "Reverse Closed-Loop output" instead. FYI same signal can be used to invert the output of a slaved Talon SRX.

Also EncRising isn't available in LabVIEW (Section 21.7).

[min and max output]
Not supported, didn't have time for it. That's also what Section 21.4 is about.

[bang bang]
I suppose it's possible to do Bang Bang with a large P. Then once the speed meets or exceeds the target speed, the motor output would coast. I can't say I tried using it in that fashion, if that works out then please share with the rest of the community.


All times are GMT -5. The time now is 00:52.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi