Currently we can auto-align to the speaker, and are using interpolation to get the right angle for our shooter’s pivot and right velocity.
I want to minimise time wasted for things like revving up the shooter wheels, and possibly our shooter should try to get up to speed before we stop to shoot (to not waste time)?
Has anyone been able to achieve this?
In previous years we’ve picked a steady-state RPM to keep the shooter at when not in range of the target. We found that maintaining that target speed ended up using less power then revving up from zero all the time. Our plan is to do the same thing this year.
The catch is that your mechanism must be able to keep game pieces from contacting the shooter until you are ready.
Yes, we have; we made a boolean-type method in our outtake subsystem to check if the shooter wheels are up to speed.
You can see the implementation in our OuttakeSubsystem and OuttakeNote Command.
The line is currently commented out in the OuttakeNote Command, but the implementation structure is still appropriate for use.
If your already using vision to find the angle you shooter needs to be at you could easily add a couple line of code to say (if we are within x meters of the speaker Shooter Wheels ramp up to X rpm)
I am on the same team as OP. The problem is that we are having power consumption issues - and I’m afraid that constantly changing the rpm based on our distance would use a lot of power.
We will still try this out though!
Don’t change your speed Just pick a Nice RPM the motors are happy at. Were spinning up to around 1500Rpm when we get within 7 meters of the speaker then spool up when we intend to shoot.
If you keep changing them once you are within 7 meters, doesn’t that break the intent of having them at the constant rpm to save power?
we only change them once the shoot command is pressed. So they sit at a steady 1500 rpm Until the Operator Holds down the shoot button. it cut our spool up time nearly in half
You could use a manual alternative. Implement shooting as a 2-step process. Press button 1, and everything gets up to speed. Press button 2, and it feeds the note into the shooter. Then it comes down to training, and getting your drivers to understand how long it takes to spin up so they hit button 1 at an appropriate time.
If we know that we are scoring in the amp, and need to make a handoff between the shooter and our amp outtake, should we just power down the motors to 0 output until the handoff, or have them rest at the output we want for the handoff until it happens?
We set pur robot to either amp mode or speaker mode. In amp mode we dont spool up anything ahead of time.
I’d like to keep things as automated as possible, so while this has been in the back of my head for a while, I’d like to avoid it.
It depends on the amount of change, but in general we found changing the speed by even a 1500 RPM didn’t draw a ton of power. How heavy are your wheels? A small flywheel or might help, as you’ll be spending less power to hold a speed.
Are you monitoring the power usage on the shooter’s PDH/PDP channel to see when it spikes? Also, have you checked your PID gains to make sure it’s not oscillating around the set point? That could could lead to more power usage.
Also, if you haven’t already, make sure your motors are in coast mode.
We moniter in Driver station, and it goes from 12 to 9 volts when just running the intake and shooter. We were testing with max exertion (motor.set(1)) and got this result. We’re pretty behind and haven’t tested with PID yet.
We have small wheels(4 inch stealth wheels and compliant - although we are making a switch to all stealth).
It’s not just about power, but we also want speed. I think I’m leaning towards leaving them at 0 volts when in amp mode, for less time to revv up.
Lastly, what difference on power consumption does brake and coast mode make? We use brake mode on our arms to keep them at their setpoint, but everything else is probably coast. How does brake vs coast affect shooter motors?
If you’re using brake mode, it will use power to slow the motor to a stop. This is useful on mechanisms that hold position, but a high RPM wheeled shooter will eat power as it winds down.
Are you seeing those voltage drops with a freshly charged battery? Normally if we see that, it’s time to swap batteries. You should check out the Driver Station Log Viewer. You can graph the power draw of each PDH/PDP channel. Check where the spikes are, it may inform you strategy overall. It might also highlight a mechanism that is having issues (e.g. friction) that cause it to draw more power than it should.
Thanks!
Should I make both shooter motors follow each other if they have different resistances to movement? Also, do I need to call the follow method once?
You’ll want to make one motor the leader and one the follower. You only need to set the relationship up once upon robot init.
And you’ll want to do that even if you don’t think the motors behave differently, because they do behave differently. You just might not notice. Yet. Reality is there’s no way your wheels, belts, pulleys, motors, etc all behave identical on both sides. As parts wear the differences increase.
So, that’s where PID comes in. You can either use two PIDController’s from wpilib in your code to keep each one at a target RPM or offload the PID to the motor controller and set them up in leader/follower. I like starting with software PID and then moving to hardware PID as we get some reasonable constants determined for the PID loops.
It’s also important to keep performance constant as the battery voltage changes. You wouldn’t want your early game shots being faster than later ones.
You also might find that cranking it to 11 isn’t the best solution. Testing will be important. You might find that the robot as a whole vibrates at certain RPMs and causes shots to wobble off target.
STEM is fun, ain’t it? 
Perhaps you could use lighter/less wheels on your shooter? Our shooter ramps up pretty quick with 8 stealth wheels.
You can also do clever things to precharge the shooter. You can charge the shooter if you detect a game piece in your robot, or when you are within a certain distance of the speaker (using vision).