Swerve Drive turning pulley ratio


But let’s say when the robot powers up the encoder reads 0°. If the encoder is geared 2:1, you won’t be able to tell if the module is pointing at 0° or 180°. Both module positions give the same encoder reading. You would need some indexing routine to determine which way the module is pointing at startup. That’s the reason why many modules are designed with 1:1 absolute encoders: there’s no need for any kind of indexing routine.


Ok. I think the confusion arose from me not 100% understanding what an encoder was (got it mixed up with incremental) I completely understand why now. Thanks!

I’m not a programmer but do the encoders hold the degree value even if the module moved around while the robot is off.

Ex: Robot ends match where modules are at 0 degrees. Maintenance is done on the robot while powered off and the module has now rotated 30 degrees. Upon powering on, will the encoders read 30 degrees or will 30 degrees now be the new 0 degrees.

Absolute encoders do, such as the MA3 or the CTRE Mag Encoder in absolute mode.

1 Like

Part of the rationale is that you actually don’t want your module to turn too fast. Let’s say your robot is traveling full speed (linearly), and your driver moves the joystick 90 degrees. If you could instantaneously rotate your wheel 90 degrees, your robot would probably flip over. Keeping your module turning speed to 200 RPM is in the right range to prevent this from happening. For a top-heavy robot, you probably want this to be even slower.

You could certainly do this limit in software. But gearing down the motor so that it runs in that range around about 10V makes things easy on the electrical system. You should see very low current usage if you set it up like this.

It does beg the question as to why some teams use high powered motors to do this - I’ve seen plenty of teams use Neos or Falcons, and this never made a lot of sense to me. The extra weight and space they take up is overkill when something like a Banebots 550 will do the job just fine. Sure, you need to gear those little motors down a bit more, but it still seems like the right choice to me. This year we used the NEO 550 because it is the smallest and lightest legal motor.

1 Like

Another factor to consider is backlash stackup in the steering gear drive. A 1:1 encoder will do a decent job of measuring the actual position of the pod, but a 2 stage planetary reduction will still often produce a lot of backlash (3-5 degrees of slop/play) between the steering pod and the drive motor. Putting the encoder in a planetary box that steers the pod via 1:1 belt drive locks you into this backlash. Mounting the encoder independently of the drive system opens the potential for a single stage planetary with supplemental reduction in the final drive, with a corresponding reduction in backlash.

Hey I was recently designing a swerve and while doing so was looking at the wcp swerve. Maybe my calculations are just way off but with the falcon they’re using their pushing around 500 rpm. Is it possible they just dial down the speed in programming?

Disclaimer - I have not used the WCP swerve module.

Based on the assembly manual, it appears your calculations are correct. It looks like the gear ratio from the motor is 12:1 (72:18 * 24:8). So with a max free speed of around 6000 RPM, you end up with a module rotation speed of 500 RPM.

By running the modules at this high of a rotation speed, you face 2 potential problems - 1) not having enough torque in the steering motor to hold the steering position (reacting against the drive motor reaction torque) and 2) having a stable control loop. Since the Falcon has such a high stall torque, the first potential problem is not going to be an issue. To address the second potential problem of controlability, the control loop will need to run in the motor controller (with its faster loop time) instead of in the RIO.

Speaking from experience, we migrated our steering control loop into our motor controllers this year and increased our module rotation speed to 330 RPM and we were able to have a rock solid control loop with no jitter and reasonable damping. I believe 500 RPM is certainly do-able, especially if you use the motor’s built in encoder rather than trying to close the loop with the absolute encoder. This would get rid of the backlash between the motor and the module (and the associated deadband in the feedback that leads to over correction and jitter). You would still need the absolute encoder to at least initialize the module position.

It would be interesting to know whether you can close the loop on the absolute encoder and have a stable control loop without slowing the motor down a little. My gut is telling me that it would be marginal, but without trying, it is difficult to say. Damping can get you pretty far, but with the deadband affecting the feedback, it is hard to predict whether it would work or not. But you have plenty of torque margin to be able to slow the motor down if you needed to.


The ideal rotation IMHO is around 3-4 rev/s which turns out to be 180-240 rpm @ the steering section. 1323 used the non bldc swerve by WCP in 2019 and bldc version in 2020. Both these swerve’s don’t have enough gearing to reach that speed.

Luckily both the 775pro and Falcon have enough torque where you can just run the motor at a lower voltage. I believe the team ran them at 6-8V per motor and had great performance. The falcon this year at the steering, heck on the entire swerve was pretty awesome.


Example: Ride a bike and yank the handlebars 90 degrees to the right. If you do it quickly enough, it won’t be pretty. All the momentum has to go somewhere and a slightly slower steering speed allows smoother cornering.

1 degree/ms or 166 RPM working or 180-240 RPM free speed, as stated, is a good rule of thumb.

If the system is geared for 500 RPM free speed and you put a voltage cap of 6V then your new free speed number is 250 RPM. This is a big clue that the motor is too big for the application.

Turning an azimuth shouldn’t take more than 10 Amps.

Our experience with turning faster than the robot can move is the robot under steers or “drifts” and the wear pattern on the wheels reflect this. Luckily the CG is low enough so no tip over from turning.


I agree that turning the modules fast when you are moving fast is not a particularly good idea.

However, when you are moving slow or when you are stopped and want to pull away in a different direction than when you arrived, it is helpful to have the modules be able to change direction quickly.

For example, with this year’s game, suppose you come through the trench and then stop in your shooting position near the end of the trench run to shoot. Your wheels are aligned pointed toward the endwall. You shoot and when you are done, you want to go sideways toward the rendezvous zone the hang. So you move the stick on the controller full to the left and the modules need to spin 90 degrees before you can start moving. While the difference between 90ms and 30ms to rotate the modules is likely not going to make or break your match, if you were to perform similar maneuvers from a stop multiple times in a match, it could add up.

The difference in response time was noticeable to us on our practice field when we compared last year’s robot (150 RPM free speed - RS550 with a control loop on the RIO) with this year’s robot (330 RPM free speed - NEO550 with a control loop in the SparkMax).

1 Like

It’s always possible to limit the rotation speed based on velocity. One could use Motion Magic and send periodic cruise velocity updates to your turning Falcon/Talon, or use the WPIlib tools to do this Rio-side.

In any case, “turning too fast” is a driver problem, not a problem inherent to the drivetrain. The ability to do fast direct changes at low speed is valuable IMO.


Right. It’s a driver skill that can be assisted by software and/or mechanical limits on steering speed.

Software limits on speed are easy to implement (although we haven’t seen any need for it on our WCP V1 swerve, geared to 330 RPM on a 775pro). Getting the module to turn faster than its free speed is a bit harder.

1 Like

I can’t tell if you think we’re disagreeing or discussing. Please clarify.

Did you ever feel like you reached a limit on the amount of torque available for the steering at the 330rpm? I currently have a final speed of 390rpm on my module and was curious to see if this would be pushing my luck too much, so your switch to the 330rpm would be a good initial indicator. Luckily with the UltraPlanetary on mine I can always add a second stage to increase the reduction at the cost of 10mm of height, but I would obviously prefer to keep it at a single stage.

1 Like

Lemme know when you figure that one out, Anand :wink:

We’re running a 775pro with a 42:1 reduction (450rpm free speed) and we haven’t had any issues with it yet, the motors are some of the coolest on the robot. I think 390rpm with a neo 550 is reasonable

No, there was never any evidence of having inadequate torque to achieve or hold a desired steering position.

Obviously with the shortened season we did not have as much drive experience this year as we had in previous years. But, we did push some robots around in our one district event and our drive ratio this year was increased to 8:1 which should have been more challenging to our steering motor’s holding torque than our higher speed ratios of previous years. So, I think we have have subjected the new modules to a decent test.

I would say that the 390 rpm speed that you have selected is probably going to work. But, obviously it depends on the drive motor gearing and the associated reaction torques. I sent you a DM a while back with our math and logic for sizing our steering ratios. You may want to plug in the numbers for your module and see how it looks.

Also, I believe the maximum load case we need to worry about is when the drive motor is applying max (stall) torque to the modules. You should be able to run a fairly simple test where the robot pushes as hard as it can against a wall and you should be able to watch the modules to see if they hold position. You could even turn them slightly to the left and right and see if they have the torque margin to turn the modules to the commanded position. I don’t know if you have built any of your new summer modules yet or built up a driveable chassis yet, but if you have, that would be the test I would run to check.