*I’d like to know of any teams which have successfully used Talon motor controller for shooter-wheel bang-bang speed control. Thanks.
We did it. But it’s not going to be on our competition robot.
We put a strip chart on the Dashboard to display the RPM as measured by the encoder. Our programming students decided they weren’t satisfied by the amount of overshoot it showed, and implemented a simple PID controller. A few minutes of tuning later (plus some tweaking of the algorithm to limit integral windup), it works great.
The continual loud snaps and clicks from the gearbox when using bang-bang were rather disturbing to most people hearing them. The simple PID sounds smooth as silk, appears to bring the motor up to speed just as fast, and recovers quickly from a brief additional load without problem.
Did you get the same disconcerting results with a Victor?
Very impressive it the performance is truly comparable.
Are you doing PID on velocity itself?
Is it output = PID, or output += PID?
Are you using all three terms?
Are you limiting the motor to never allow a negative power applied?
We did on our prototype shooter. We had no problems direct driving AM pneumatic wheels with CIMS from the Talons.
The final robot uses Victors for controlling the shooter, as excellent linearity is not needed for bang-bang control.
Oops.
The programming group is using a drivebase built out of the Kit chassis this year. Its drive wheels are controlled using Talons, and the actual robot has Talons installed for the shooter motors, and that’s what I was thinking of when I answered the question.
However, the shooter test rig on the Kit 'bot was wired up using Victors. I’m sorry for the bad data.
Both the setpoint and process variables are in values of “kRPM”.
After we discussed the fine points of position vs. velocity control, I believe the student doing the programming chose to send the output of the PID computation directly to the motor rather than doing a post-PID integration. I was busy with other tasks while he was tuning it, but I’m pretty sure the D constant ended up being zero, and the P constant is probably negligibly small. Most of it is I, as one would expect from a velocity PID.
The output is indeed limited to never apply power the motor in the “wrong” direction. There is a use case where the shooter motors must be run in reverse, so the control software keeps the output either positive or negative as appropriate, based on the polarity of the desired velocity.
We are using bang-bang control on Talons with two 4-7/8" wheels (I think).
We painted half the wheel white and used a light sensor to measure rpm. All of our shots went in at Lone Star when we positioned our robot correctly.
Would a spike relay have a snowball’s chance of reacting quickly enough for a bang-bang controller?
Even if it could, I wouldn’t feel comfortable having it switch that fast. Remember, it’s a mechanical relay. Something is actually moving in there.
Well drat. There needs to be a tiny FRC-legal motor controller that does full-backward, stop, and full-forward only.
We found the same. The bang-bang sounded horrible, and had a bit of a sine wave on our graphs. This was probably a result of an update time that was too slow. It was easier to review our code from last year and implement something similar. We don’t even have to retune it from practice to comp bot.
Slow loop timing could easily cause both overshoots and undershoots.
Additionally, one of our local teams used a slightly modified Bang-Bang to resolve the “The bang-bang sounded horrible” issue. What they did was increase the “off” state drive from “0” to 30% power.
They also added a second case to completely stop the motor when not needed.
We had a lot of this at first. When we set up bang-bang on our shooter, our encoder outputs were jumping around by about 300 rpm, and even with direct drive off a miniCIM, bang-bang didn’t sound very good.
Eventually we convinced the rpm function of the counter class to use the FPGA timer, and the numbers settled down very well.
Then by having the code attempt to update the Talon output every millisecond we eliminated almost all of the overshoot and variation. It is changing state so quickly now that the motors sound just as smooth as ones receiving constant PWM.