So our shooter motor is powered by 2 CIM motors and uses an encoder for us to readback the velocity of the shooter. We then have a feeder powered by a smaller motor.
When the two shooting motors get up to velocity, our software runs the feeder motor to push a ball up into it.
However, we have noticed that when the feeder motor comes on, the velocity of the shooting motors drops, so the ball will be going through at a slower speed than we need. There is no way we can run the feeder motor before turning on the shooting motors as we would push the ball into the wheels.
I am guessing the feeder motor is pulling away from the current of the shooting motors. The shooter motors donāt need to run at absolute max velocity, but they do need to run pretty close to that to be able to make the shot.
We have a Cross the Road Power Distribution board, as well as everything on talons. I am wondering if I can set the shooterās motors to āpriorityā or do something with the talons. I would think if teams could support 6 cim drives, we could run 2 cims at near full output with another motor running. Am I wrong?
If you have 3 motors, all limited to 40 amps max, the battery is more than capable of supplying them.
If those motors are not current limited, you may be pushing the battery near itās threshold.
Even a slight reduction in voltage will reduce the top speed of your shooter. Your best bet is to use the built in voltage compensation and set that to around 11 volts for your motors. Then change the gearing on the shooter motors so that they are running at about 1/2 to 2/3 their rpm at your shooting speed. That should give you enough overhead that your closed loop control can compensate for the other motor coming online.
Iām not talking about current limiting - a feeder motor shouldnāt take much current at all. Iām talking about the brief current spike that occurs when you tell a motor to go from 0 to full speed immediately. That spike may cause other motors to briefly receive less power (closed loop control on those motors may reduce that impact).
What Iām suggesting is to add a āramp rateā command which tells your controller how fast it should allow voltage changes, thereby eliminating the spike. By doing even a very brief ramp (e.g .2 seconds), you can significantly reduce the impact of the motor starting up. The ramp rate commands vary depending on the motor controller. For example, a TalonSRX command in Java would be: feederMotor.setOpenLoopRampRate(.2);
This behavior is expected (more current drawn drops voltage, affecting shooter wheel speed), but it is also something your shooter control loop should be able to compensate for. These kind of changes and disturbances are one of the biggest reasons for closed loop speed control.
Limiting the current that the feeder motor draws is a solution to the problem, but I donāt think itās the ārightā one - if this current drop affects your shooter, other factors which affect the shooter accuracy are also not being dealt with by the control loop. What kind of control loop do you currently have on the shooter? Perhaps it needs some more aggressive tuning. Can you up the P gain a little bit to react to this disturbance faster?
Control loop is simply a velocity pid. Looking back at it though we donāt have any values for P, I, Kā¦ only F.
Right now the loop checks if the velocity of the shooter is over a threshold, and then sends the ball through the feeder. We canāt physically do that part any different. Iām guessing the initial current spike is what hurts us? Although reading back and looking at the students codeā¦ no P could be hurting us too? we could adjust quicker
No values for P, I, or D is precisely the issue. The PID is not responding to when the shooter speed falls off; with only F, you are just commanding that the output voltage is a certain percent of the input voltage, and when the input voltage sags, your output voltage sags, and your motor slows down.
Put a ramp on the shooter will help calm down the input voltage problem, but other things will also cause voltage sags (heavy handed driverā¦).
Getting a working P term into the PID will help a lot.
Alternatively, if you donāt need to run the shooter motor at 100% power and are controlling with a CAN connected Talon SRX or Victor VPX, you can cheat a little by telling Talon/Victor to keep the output voltage at a percentage of a certain voltage (say, 10V). As long as the input supply stays above 10V (in this case), the controller will keep the output voltage at the requested point. Easier than tuning the PID, but not as robust (and you severely limit your output power, which you probably do not want to do with a shooterā¦)
This is precisely the issue. If you just have F, itās essentially the equivalent of just giving your motor a constant command, so the speed will vary with battery voltage.
The F value you have is fine if it is accurately shooting with no load / a full battery. In many cases, you can get a responsive enough control loop just by adding and adjusting the value for P. Lots of guides to doing this exist both on CD and the CTRE documentation.
okay. thank you so much for all of this. Make s a lot of sense.
Right now we do seem to be able to relatively accurately reach our output power, but then the intake roller comes on which I am guessing has a brief current spike. Is the idea our shooter isnāt able to recover in time with a 0 for P, I and Dā¦ and with an actual value we would recover?
Absolutely! This is one of the biggest reasons to use a control loop in FRC.
What F does is it is basically a starting point for motor power. The F gain does not respond to sensor input at all - itās a constant. The idea of F is to make it so the work that PID is doing is responding just to disturbances (lower voltage, higher load, etc) rather than having to do āthe workā of getting the motor up to speed. So if it shoots well with your current F in ideal conditions youāre at a good F already.
What P does is it adjusts the motor output proportional to the amount of error (how far away you are from your RPM setpoint). Too little P (such as 0) and no adjustment will occur, or it will occur too slowly. Too much P (without I and D) and you can rapidly oscillate around your target setpoint.
What has worked for me in the past has been to gradually up P until it just starts to oscillate, then pull back a little bit. If you are satisfied with the rebound performance at this point, cool, youāre done, you can just leave your loop as only having F and P terms.
If you want it to get to speed a little faster, up the P into that oscillation zone and add a lot of D to dampen the oscillations (D, or derivative, slows the wheel down as the rate of change toward the setpoint increases, smoothing this sort of thing out). The I term is somewhat easy to mess up so I wouldnāt use too much of that, and if you do use a narrow I-zone.
Making a graph of error over time, and a second graph of motor command over time, and running both on your dashboard, is an excellent way to quickly see how changes to your setpoints change how your loop responds.
Thank you! I am so happy this was the issue. I havenāt gotten to test it tonight but I was getting ready to go down a crazy rabbit hole measuring currents.
Just be aware that control loop tuning will likely take some time, especially if you havenāt done it before. Read all you can (the Talon SRX user guide has an excellent walkthrough) and try to set aside a couple of hours where you can just feed balls through the robot / shooter and make tweaks until it works the way you want it to. And feel free to reach out on CD if you need more help.
if I have a system in a velocity control modeā¦with only a kf, I see a drop in speed when another motor turns on.
I am guessing this is because the system now has less current available to it. How could having a PID help me fight the fact that I have less current available? Does that make sense? Is the idea it would help me recover quicker?
An aid to see if your tuning is to have your periodic() put the current velocity onto the SmartDashboard, and have Shuffleboard plot it. Good poor manās instrumentation.