Currently, we are controlling our shooter’s angle off a NEO motor connected to a sparkmax. We also use a REV thru bore encoder to get an absolute position to run the PID loop.
I’m trying to figure out how to speed up motion and make it a little smoother. Increasing the P value doesn’t seem to speed it up much. Is it because the output to the motor is small since the setpoint to get the note from the collector (which reads as 0.78 on the thru bore) is only 0.13 away from the resting position (which reads at 0.91)? How would I output a higher speed while reaching my setpoint accurately and smoothly?
PID terms are highly dependent on the mechanism youre controlling. Both 0.001 and 7 are perfectly valid values depending on what youre working with. P is proportional, so if your error is < 1, you’ll likely need a P constant on the larger side to get outputs (i.e. motor speeds) in the range you need (-1 to 1)
My team is also doing a pivoting shooter this year. What I did to tune it was set all the values to 0 and make sure your maxVelocity and maxAcceleration are at what you want them to be. Start increasing the FeedForward value until the pivot is almost moving towards the setpoint but isn’t. This is to overcome the mechanical resistance. Then start increasing your P value until it starts oscilating around the setpoint. If this is fast enough for you, you can just bring it back to what it was before it was oscilating, otherwise you can start introducing the D value to stop the oscilation.
Another thing to note. If when your shooter is parallel to the ground, it can’t hold up its weight, you may need a gravity feedforward. Here is a good starting point if you do need to go this route Feedforward Control in WPILib — FIRST Robotics Competition documentation.
Okay I will try making the P value a little bit larger. Rn it is 1, but I will try making it 10 and see if that makes it better. I also just wanted it to run smoother without any jitter and make it more accurate since rn I set the tolerance to 0.03. I’d rather just like “hold” the arm at the setpoint until a new desired setpoint is commanded.
Since it’s only 0.13 away, a P of 1 means the maximum it will command is 0.13. A P of 10 will ensure it maxes out the comment (0.13 * 10 is greater then 1).
Are you tuning the PID Controller as a vertical arm? With a vertical arm, your feedforward will depend on the angle of the arm because at different angles gravity has a larger or smaller effect.
Ah, so maybe 7, which would 7*0.13 be 0.91 (under 1). If that’s too aggressive, Ill play around till I get a better value. Still, the main problem is that the motion isn’t smooth
Not using any FF rn. Only using P rn. Wdym by vertical arm? I linked my code in the initial post, not sure if that will answer ur question. I think I am not tho since I didn’t use any FF.
“A mass on a stick, under the force of gravity, pivoting around an axle.”
“A motor and gearbox driving the axle to which the mass-on-a-stick is attached”
I think this describes the scenario of our shooter being on a pivot? The “mass” is the mass of our shooter and the wheels I guess? I didn’t use any FF and just used simple PID for the collector intake which worked fine. But do I need to use a feed-forward now for the shooter pivot positioning control? Not really sure here.
I am using the SparkPIDController class and doing motor.getPIDController(). Here is a link to my team’s repository. We haven’t fully tuned the pivot yet since it is still undergoing changes but the numbers I have right now are pretty close.
Yes, the vertical arm is the same scenario as your shooter on a pivot. Your collector intake is also a vertical arm. Both could benefit from a feed forward.
I would guess the reason your collector didn’t seem to need one is that you aren’t trying to stop it anywhere near vertical. You are likely not exactly at the set points you are calling, but the sag below the setpoint is consistent so you don’t care. It responds quickly due to a high P value, but doesn’t oscillate because it is dampened by gravity.
If you want your shooter to respond faster you will need a higher P value. But if your P value is too high, then you will introduce oscillation. Adding a feed forward will help your response speed without requiring an overly agressive P value.
Yeah, for the collector, I’m satisfied with what we have. It’s sub-optimal, but it gets that job done. Precision isn’t necessary; it just needs to get from point A to point B quickly, which it is doing.
Ur right about increasing the P value, which would introduce oscillation. So, would you recommend tuning the FF first without any PID and then adding PID on top of the FF? Do I only need to tune kV to get close to the setpoint and then tune the P value? Or do I need kS, kV, kA, and kG values too? I saw the WPILib docs with the tuning simulations, and it seems like it would be somewhat tedious having to retune so many values. I’ve heard it’s possible to do this with SysID automatically. How would I go about doing that?
When my team tuned our arm last year, the only values we needed were kG, kFF (which I think is the same as kS), and kP. If you need some guidance on tuning kG, I can try to help but I’m no expert
Correct me if I’m wrong, but kFF is only if you use Spark PID control with the .setFF() method, which equals kV in WPILib’s SimpleMotorFeedforward class iirc? kS is that static gain, which is separate from kV. Maybe I am misunderstanding what ur saying?
I’m not 100% sure. My team started switching to REV for non drive mechanisms before I got super involved in the code so I don’t know if it works with CTRE devices. I believe both kFF and kS are static feedforward values so you should be good with just using kS if you can’t use kFF. Somebody please correct me if I’m wrong.
DO NOT USE SMART MOTION!
It’s implementation is fundamentally flawed, and it does not close the loop on position, but instead is entirely velocity based. It is not capable of correcting any error in position.
Instead, you’ll want to create a trapezoidal profile in WPILib, and send the output of that every loop to the Spark Max on regular position PID mode.
Unfortunately, you are in fact mistaken here. kFF is strictly equivalent to kV (in potentially different units). kS has no direct representation in the REV API.