My team is using a neo brushless motor to power our shooter. In order to set the velocity of the shooter, I use the integration part of the WPILib PID controller. The shooter gets to the correct RPM and the first ball shoots accurately but upon shooting the second loaded ball the shooter shoots inaccurately. The feeder wheel is at 25% power. What could be the problem? What should I do to ensure that we get consistent shots?
Here is my PID definition
private final PIDController shooterController = new PIDController(0, 2e-4, 0);
shooterController.setIntegratorRange(-1, 1);
Here is how I am setting my shooter velocity
public void setShooterVelocity(double speed) {
double velocity = MathUtil.clamp(shooterController.calculate(getVelocity(), speed), -1.0, 1.0);
shooterMotor.setPower(velocity);
}
Watching the video it looks like your shooter is shooting the cargo once the rpm hits the desired rpm, the problem is that the cargo takes a some time to get to the shooter and meanwhile the shooter is in the process of overshooting the desired set point.
You should graph your velocity to the smart dashboard, glass or shuffle board to get a better picture of what is happening. It looks like you need to tune your PID constants to lower your overshooting of the setpoint.
Another thing that you could implement to ensure the shooter rpm is at the correct range by using an exponential smoothing function and checking that is at the desired rpm before shooting. The exponential smoothing function uses a weighted average to ensure a more consistent velocity before triggering the shooting
Integral-only control (P and D terms set to 0) is uncommon because it is prone to oscillation and long settling times. Given that you’re controlling the speed of a flywheel, why not use PF (proportional+feedforward) control instead?
What the others have said regarding a PF controller is spot on. Another thing you can consider is lowering your feeder speed. Your shots are coming out very fast, not allowing the shooter much time to correct in-between shots. If you can slow the feed down, you allow the shooter wheel to settle a bit more before the second ball reaches it.
As others have said, you’ll want to first set up some plotting, so you can see what happens to the velocity of the flywheel over time, especially during shooting.
Set up the motor controller in voltage compensation mode to start with. This will mean that your outputs will be in volts.
Then, try setting different voltages until the unloaded velocity (i.e., not shooting cargo) settles at about how much you want for shooting. Take the ratio of that voltage to velocity (e.g., volts per [encoder ticks/second], or whatever units it comes out in). Your entire feedforward term should be that constant (call it kF), multiplied by the setpoint you want to achieve (speed, in setShooterVelocity()), in the correct units.
Add to that a proportional term, which could come from a the wpilib PIDController you’re already using:
…or you could just recreate it. The error term is going to be [speed - getVelocity()] in your setShooterVelocity() method, you’ll have a proportional gain (kP) and the total proportional term will be kP * error.
Start with the proportional gain at 0 (as well as the I and D – leave those at 0) and try shooting a few cargo. As you slowly increase the proportional gain (alternating shots and increases in kP), the speed of the flywheel should recover more quickly after shots. As you exceed the ideal proportional gain, the settling time will go up again.
You can get more complex with the modeling/characterization as well, if this is something you’re interested in:
If you set your feed wheel to spin at max speed it is likely not up to speed before the first ball enters the shooter wheel, and it may have accelerated more by the time the second one gets there. A perfectly tuned shooter won’t shoot consistently if the feed isn’t consistent unless you have a long distance to correct for this (more than just 90 deg wrap around a wheel). The plotting suggestions are good too, but I’d be surprised if you were seeing that large of a shot difference in PID tuning.
If the team directly drives the mechanism setpoint(s) based only on the instantaneous target capture, losing vision lock can be an issue. If we expect to lose vision, auto aiming and auto ranging can be driven by a pose to the target that persists, and automatically updates using odometry, even when the vision lock is lost. This was a major technology development for 2363 this year. The goal was to build a system that could estimate the position of the robot on the field at all times using odometry (reliable but drifty) and vision (unreliable but absolute). It results in a robot that can continuously adjust the shooter wheel speed and hood angle while driving, even if the camera can’t see the target. We rolled this code onto the bot between our week 1 and week 3 events and saw our shot percentages drastically improve.
