for context: our shooter has a flywheel which uses PID on 2 talon fx motors to maintain a certain velocity.
whenever we intake two balls and shoot them immediately after one another, the first one goes in the hub perfectly, but the second one always goes long. my theory is that since the flywheel speed decreases while shooting the first ball, it tries to give more power to the motors to bring the speed back up, which then results in the second ball being shot with too much power.
has anyone else encountered this problem? if so, what did you do to solve it? (other than waiting a couple of seconds between shooting each ball)
quick solutions are preferred if possible, as our next competition is April 1
We had a similar issue. Are you sure it’s the PID, or maybe something else in your robot introducing that extra velocity? What we found was that the first ball sat right underneath our flywheel, so when we shot it, it didn’t have that much momentum, but with the second ball, it had the momentum of our feeder carrying it upwards.
I believe that that the flywheel in question is the wheel that contacts the balls. A flywheel she’s not necessarily have to be an extra wheel for inertia. All the wheels are flywheels. Your Fairlanes, for example, are the flywheels.
My team had a similar issue, albeit with 2 PID neos. To echo Sampajama, we figured out it was the variable velocity of the ball before it got shot. The second ball had a longer distance to travel/gain speed, and therefore the arc was being altered.
Take a look at the phoenix tuner plot for velocity. We’ve also had success using a shuffleboard graph with the setpoint and current velocity so you can see them in relation to each other.
I would recommend using kF or a feed forward to get as close as possible to the target velocity then experiment with a kP in the range of [0, 4*kF]… (Upper bound limit depends on your specific wheel assembly and system response)
A ball accelerating through a shooter is a violent event. Working with the assumption the pid is overdampened and never exeeding the rpm setpoint (big assumption, check using a grapher) the geometry of you shooter may dictate that more energy is imparted at a lower rpm
(Just trying to explore edge cases, I suspect the PID tuning is not playing nice with your shot sequencing, and that’s the first thing to check.)
The way you are delivering the balls to the shooter can also affect this. For example, let’s say you have the balls stored in a tower with an elevator made from urethane belts or polycord. If this first ball is stored very close to the shooter, when you turn on the belts to deliver the balls to the shooter, the first ball will get there very quickly, meaning it will not have had much time to accelerate. So it will be traveling slowly when it hits your shooter wheels. The second ball has more time to accelerate in the tower before it hits the shooter wheels, so it is traveling faster when it reaches the shooter wheels. The extra incoming speed of the second ball maybe enough so that it more-than-overcomes the loss of shooter wheel speed from the first ball.
This is actually the exact thing that happens with our robot this year. We were very surprised to see it at first; based on experience we were expecting the opposite outcome (first shot goes farther). But I think with the powerful brushless motors that we have now for shooters, plus a big flywheel mass, we’ll see setups where the shooter wheel can recover so quickly that this might become more common.
… If you have a turret, how you are yanking the ball out of the feed belts matters too. This is one inconsistency we found with the 2020 game pieces and our shooter geometry. This year we have a small elevator section that rotates with the turret, guaranteeing the ball is always fed into (and pulled out of) the feed belts identically no matter the turret angle.
I agree with the others that it is likely that it is the feed into the flywheel that is causing the problem. The flywheel accelerates the cargo so if the second cargo comes in with more momentum it will have a higher exit speed.
Check the Phoenix Tuner velocity graph for both your index and your shooter to see what’s happening. Our shooter definitely also has a tiny “overshoot” period as it oscillates around and zeros in on the target velocity, which is typical for a high P-value. I preferred that to a lower P-value that takes longer to get to the target velocity. Maybe I could get rid of that with a D term? I’m frankly still learning how to do PID tuning correctly. I didn’t even understand FF properly until this season, and I’ve been doing this for five years.
Is your indexing system also PID-controlled? We use a velocity PID on our index belt/wheel system, so the speed from the index to the flywheel is also absolutely consistent. We also use a POSITION lock PID control on the indexer that doesn’t move the index until the shooter is at the correct speed; when intaking it stops the ball when it hits the limit switch, so each ball going through the index always does exactly the same thing at the same time. (We’re using two PID profiles on the TalonSRX on the index, one for velocity and one for position, so it’s always either locked in place or moving at a predictable speed.)