Is there a need to add a feedback control to Turret

Our team wants to use a turret in this season . As we all know, when controlling the turret, we should use position control. From my perspective , there is no need to add a PID control(mainly the position closed loop) to a turret, since no force will disturb the turret.

Any suggestion is appreciated!

1 Like

If you want the turret to accurately line up with the hub you should use closed-loop control. It’ll be pretty hard for a driver to line up correctly.

1 Like

I don’t really see any advantage from foregoing the PID.
Feedforward will never be perfect and I wouldn’t be surprised if there were inconsistencies while turning that resulted in noticeable error.


How do you plan to control the turret?
Using vision? Manually?

1 Like


Our 2021 turret had no problem locking onto the high goal with just a simple feedforward in the direction of travel. Start with something basic then upgrade later if need be (and you have time).


We had a turret on the robot for these last two years. We initially programmed it for closed-loop position control, but I didn’t like how jittery it was. We had quite a bit of friction in the turret and going with a more powerful motor helped with getting good PID values, but it still moved too much for my tastes. Instead of trying to incorporate some sort of tolerance to only allow the position to change once it was more significantly off-target, we changed it to velocity closed-loop control. This worked out much better for us. If the error was large, we’d send a large velocity, if the error was small, we’d send a small velocity. As the turret moved toward the target it’d slow down and then stop once it was on-target. This gave us a much more fluid moving turret. If we had less friction, I’m sure it would have been even better with velocity control.

Isn’t that just a better tuned P controller?


You will have to close the feedback loop on something (even if, in practice, this means using the driver as the feedback loop), or else you can’t aim the thing.

As @UnofficialForth mentioned, you can likely start by skipping position feedback (as measured by an encoder) and instead close the voltage control directly on the output of your vision pipeline. This isn’t perfect, but it’s a lot better than nothing.


If your turret can survive hitting it’s own hardstops, has a small enough range of motion, and you’re just aiming at the goal with a P loop off limelight error (motor output = kp*tX) you can probably skip a turret sensor with no regrets.


Do you have some level of position sensing on the turret azimuth? any level of encoder or software hardstop is useful and can be done relatively cheaply.

The two routes we are looking at for our inaugural turret:

  • Use three microswitches detecting a groove under the drive gear ring; clockwise, counterclockwise, and centered. Pick a point and zero the NEO550 encoder there. The third one is so that we can zero quickly!
  • Install an extra gear on the big ring gear chosen so that it rotates less than 10 turns over the full span. Couple this to a 10 turn pot with a shear-able coupling (in case of “oops”). This will give you an absolute linear encoder, but with some backlash… If you sandwiched two thin gears with a torsion spring you could make it anti-backlash!
1 Like

The 10-turn pot approach works quite well in my experience. It’s nice getting an exact position as soon as you turn on the robot with no worries about zeroing. Make sure you have spares, even with a shearable coupling, it’s easy to break the internals.

1 Like

Using vision , especially limelight.

Yes, l have thought about this yesterday and l found that l only need a PID Controller to calculate the error and set the corresponding percentoutput to the turret motor. However , is a P loop quick enough to aim at the target?

How do you calculate the feedforward?

The 973 2019 and 2020 limelight routines were just PD with pretty minimal D. Would’ve worked fine with P only if a bit slower, or on something like a turret which is just inherently more controllable.

Ah, I was being a little to liberal with my use of the term Feedforward. I meant to say “a constant power applied based on whether the turret was to the left or the right of the target”.
The best way to calculate this is by just putting in a value and seeing what it does. (Start on the low end and work your way up)

This is a very simple method, but it can be useful to “get something working” to allow mechanical time to understand their mechanism and refine it. This also allows you to iterate on your code.

It would certainly be a similar effect, but the error we were eliminating was in the vision targeting. If our target wasn’t in the center of the camera, we were adjusting velocity to get it there. And making sure the motor was running at the commanded velocity was a closed loop. As battery voltages change, the velocity stays consistent, rather than just adjusting %Vbat sent to the motor.

What you described is a P controller with a heading error input and heading rate command output, then a P controller with a heading rate error input and voltage output. It can be shown with block diagram transformations that there’s an equivalent PD controller with a heading error input and voltage output (P controls heading and D controls heading rate).


Hello , is there an optimal angle for this year’s shooter, if we don’t have a hood to adjust our angle.