Good afternoon, Chief Delphi! This year is our team’s first year doing servos, and we’re unsure about which one to get. We’re thinking about using a servo to position the shooter mechanism (about 60 degrees of rotation). We figure we’ll need about 1.5 Nm of torque for that. We also need one for a “boot” mechanism to push the boulder into the shooter mechanism, which will need considerably less torque.
We’ve got quite a few questions that we thought would be best to post here.
What are the benefits of a “metal gear” servo? A “ball bearing?” servo? Is it worth the extra price? What other factors should be considered besides torque and size?
It seems advisable to hook the power up to the VRM instead of the roborio (for current reasons). Is that legal?
It’s also an option to gear down a bag motor and use a potentiometer in a PID loop. Is that a good idea?
How does one adapt the servo output onto a normal old hex shaft?
This year, the biggest limitation is the practical one pointed out in the blue box below R29:
For servos, note that the roboRIO is limited to a max current output of 2.2A on the 6V rail (12.4W of electrical input power). Teams should make sure that their total servo power usage remains below this limit at all times.
You should also look up the maximum current draw of each servo and manage this current limit.
Metal gears will likely be more robust in the case of collisions. Ball bearings will likely have less friction than bushings; in most problems with an answer of servo, this is not critical. You also want to consider speed - a high torque servo that takes 30 seconds to do a two second task isn’t doing you any favors. (exaggerated, of course)
VRM: (emphasis mine)
If you’re going to need 12W or more, absolutely. Make sure you include a hard stop in turn angle so you don’t break your potentiometer.
If you have access to a mill, you can mill the spline pattern into the end of a short piece of hex shaft. However, If you’re thinking of doing this, re-run the numbers, as these two systems are designed for different amounts of torque.
Rev Robotics also makes a servo called the Smart Robot Servo. Here are the features of it from their website.
The REV Robotics Smart Robot Servo (SRS) is configurable metal-geared servo that takes the guesswork out of aligning and adjusting servo based mechanisms. One SRS can be used as a standard angular servo, a custom angular servo, and a continuous rotation servo by simply changing its settings.
Default Operation
Out of the box, the SRS operates like a standard 180° servo, responding to a 500μs – 2500μs RC servo pulse.
Smart Features
Unlocking the smart features is simple with the REV SRS Programmer (REV-31-1108 – sold separately).
Angular Mode
With the press of a button, the SRS Programmer can set custom angular limits without removing the SRS from the mechanism. These custom limits eliminate the need to fiddle with servo horns or linkages.
Continuous Rotation Mode
With the flip of a switch on the SRS Programmer, the SRS can switch from angular mode to continuous rotation mode. The SRS saves time and money by preventing the permanent modification of standard servos.
I would definitely go with a BAG motor, geared down, in a PID loop. Or a window motor. Any hobby servo that is legal in FRC will probably not be powerful enough to do what you want it to do, and if hits a bump it will move it a lot.
… limited to a max current output of 2.2A on the 6V rail (12.4W of electrical input power).
It’s not about breaking the servo pot, it’s because servo operation by the rules is limited to a connection on the roboRIO that supplies a max 12.4w, any mechanism that needs more than 12.4w of power needs to be powered by something other than a servo.
Two separate things. As Mark said, 12W is the supply limit from the RoboRIO.
The hard machanical stop is to keep your potentiometer from mechanically breaking. In FRC you can pretty much count on any mechanism taking more torque than any normal potentiometer can withstand, e.g. in a collision.
Probably. You had mentioned using a potentiometer, so I went with that. I cannot recommend an absolute encoder because our team’s one experience with them went badly. Based on answers to questions after it was too late to fix the problem, I suspect it was the programmers not understanding the laws of physics (in particular inertia), so YMMV.
For the servo that is pushing the boulder into the real shooter, a pair of limit switches is another alternative, less expensive and even simpler to program.