our team wants to build a turret for our off-season robot, we would like for the turret to rotate simultaneously with the robot.
in order to achieve, we need to now first which gear ratio to use for the turret’s rotational motor.

our team currently uses an L1 swerve but we are planning to upgrade to an L3 swerve, the turret will use neo 1. 1 and the swerve will use kraken.

please forgive for my lack of English skills, I am not a native speaker

There are a few extra bits of information that would need to be known to really make any answer useful to you, a lot of what weight is this and that, and some preferences of things like the gear for your turret ring. There are also probably 1 or 2 other things that aren’t coming to my mind.

So instead of answering your question, I have linked a copy of the Google sheets doc that NoMythic will use to calculate this sort of thing. Not sure where we originally got it as it predates my time on the team, but here it is.

What you should do here is make your own copy of the Google sheets doc, and then enter the info into the single speed drive train sheet for your L1 or L3 Swerve drive train. (The gear ratios for the swerve modules should be on the manufactures’ website.) I would then make a copy of that single speed drive train sheet and fill in the info for your turret as if it is a drive train and play with the gear ratios until you are happy.
To my understanding, this should get you right about what you need.

If you have any questions, I’ll be checking Chief Delphi every now and then tonight.

If your design constraint is to rotate at the same speed of the robot you will also need the size of the frame (wheel is driving on a circumference of the robots rotation circle, so to convert that module speed to an angle you need to know the radius)

I will say trying to do this fast is a good exercise. Since turrets will almost always have wires you will need to quickly slew the turret range of motion to wrap/unwrap, so experience in designing for spinning through 360 degrees of motion quickly is very useful. (This is especially true for full rotation turrets, which is most years, 2020 was the exception with lots of sub 180° designs)

I would advise against using the free speed of the motor as the sole value in your calculations for the module speed and the turrent speed. A lot of these motions that you will be doing are more acceleration dependent than top speed. Look at the motor curves, play with the gearing a little. It would also be a decent idea to keep the moment of inertia low on the turret, this will dramatically reduce the load on the turret motor and give you a bigger window to play with for gearing and controls.

I’d gear for the turret to have about 2x the free rotational speed of the drivetrain, it should be a decent starting point. Generally, you need a lot of torque on turrets because it takes a deceivingly high amount of torque to accelerate the mass of the turret, and for most mechanisms, acceleration matters more than free speed as optimally-geared turrets often aren’t able to reach their free speed for short (under 180 degrees) movements because the motors can only apply so much torque.

It is possible to use a dynamics simulator to find the optimal gear ratio, but there aren’t any good ones out on the internet and you would need to spend a bit of effort making your own and often require knowledge beyond most FRC teams to successfully write and use.

I’ll recommend my AMB Design Calculator as a first step for finding the proper gear ratio. You’ll need to know how fast you want to turn (i.e. faster than your drivetrain can turn), how much force your turret needs in order to turn (a rough estimate will be fine), and the type of motor you want to use.

I want to explain a little more. When your chassis starts rotating and you pass this information to the turret, the turret will be lagged behind and will need to ‘catch up’ to be pointing the right direction. In addition, if you are rotating and start translating (shoot on the move) you will need to turn your turret even faster because you are accounting for the chassis rotation AND the motion of the robot.

So 2x is a great place to start.

I usually come at this sort of question from another angle. Given the motor I’m using and the mass of the turret, just how fast I can I move it? Might as well go as fast as feasible.

If you don’t want to do the math you can also “steal from the best, invent the rest”.

254’s 2020 and 2022 turrets had Falcons powered ~50:1 and ~45:1 reductions. Our 2024 turret had a Kraken powering ~45:1 reduction and its shooter was quite big/heavy because it also included the spindexer. Effectively, these big brushless motors are very strong and overkill for a turret, but it means you don’t need much reduction.

Why didn’t I think to just copy 254 when we were selecting our turret gear ratio this year?

Here’s a snippet of the numerical analysis I did for 118’s 2024 turret. Equations and rough estimates are included for inertia of both the turret head and the motor rotor. I looked at two components to estimate an overall torque: the torque required to accelerate the load/gearbox inertia (τ=Iα), plus a constant drag torque expected from the wire bundle. I’m not sure why the current drops below zero in the third graph but the peak current and time-to-target align about right with what we saw on the built system. If you are going to do your own analysis, be sure to set the endpoint of travel to a velocity of zero, as I forgot to do. This should end up showing that a greater reduction, closer to 254’s 45:1 gives a faster time-to-target with an acceptable current draw.

118 has pretty much halved the gear ratio on our turrets each year we build a new one, and think we found the limit this year. For 2024, we selected a 30:1 Kraken with a spur gear set we could swap to get a little more or less reduction if desired. We probably should’ve swapped to a ratio with a little more torque, closer to what 254 ran, since we ended up running only half duty cycle since the input data from the goal tracking camera was at too low of a frequency to utilize anywhere near the peak of the actuator. 254’s turret was also tuned much better than ours, pretty much fully keeping up with the drivetrain at all times where ours oscillated pretty badly. Our rotating mass must have been greater too with our amp mechanism being carried around by the turret.

@Torrance I really only share ours because for once, 118 had less reduction on a mechanism than 254. With all the linear mechanisms y’all build, I’m certain 254 has the highest ratio of blue banners to gear teeth of any team.

There’s an easy solution with cascasde control in which you feed both a position and velocity target to the robot where the velocity target is added to the result of a position controller.

How is this this spreadsheet formulated? An “efficiency” value is not a particularly accurate way to represent the total losses in the system and I’ve had better luck accounting for them by deriving models from the fundamental dynamics and accounting for losses as dry and viscous friction, resistance, and the torque constant.

I came up with a very rough estimate for the inertias of the motor rotor and a theoretical turret “head”. This was before any part of the shooter itself was designed. I then put a spring scale on a prototype wire bundle on a testbed to find a constant torque load. I multiplied my measured force by something like 3 or 5. All very rough estimates for load.

I built a discrete solution using small time steps starting from what torque the motor experiences at each point in time, which has the two contributions I had estimated, one that is constant in time and another that varies with the speed of the motor, requiring some more data.

So I went to the 8V curve data .csv from motors.vex.com for a Falcon 500. Again, very rough estimation because we planned on using Krakens if they showed up on time, although I could not find similar data for them anyway. That table gives a torque that the motor can supply for the given speed it is currently at. The torque found from that table goes towards the the drag torque (coming from friction, so expected to be essentially constant), with any leftovers accelerating the system’s inertias. From Newton’s second law in a rotary reference frame, this gives an acceleration, which is applied over a discrete time step to give the speed of the motor for the next point, which then gives the torque the motor can exert based on the table from VEX, and so on. I iterated smaller time steps until the solution appeared to converge.

I did not apply any mechanical efficiency factor. There are certainly more accurate and precise ways to estimate performance but they’re only as good as the known variables, which at the time were very few. Build season is fast. I’m still learning the valuable skill of doing less math and more doing.

If you just request the position while trying to track a moving target, you will end up with significant lag because that is equivalent to requesting the position with 0 velocity when you really want to be traveling at the input velocity when tracking a moving target, which results in the D term in standard PID to try to bring the system to 0 velocity which is not what you want. With cascade control, you can simply feed the position controller output + the target velocity into your velocity controller which will fix the lag caused by moving inputs.

Yea that’s will get you tracking moving target, because you have the velocity target. You can also really easily add feedforwards and real-time motion profiling for improved performance.