I was looking at the document that can be found on this thread paper: Stryke Force 2767 2018 CAD/Code) from team 2767 and saw that the pulleys they used for their turning motor was 1:1 (2nd to last bullet point, page 12). I have also heard lots of other teams say that it is best to use a 1:1 ratio for the turning pulleys. I was wondering if anyone knew why this is.
Thanks in advance for any help you can offer
At least for us, it comes down to not needing it. We run our azimuth as a 100:1 gearbox, so we have no need for another gearing past that. The 1:1 is purely just to transfer the motion from the gearbox to the rotational pod.
If you’re using an absolute encoder on the output of your gearbox going 1:1 enables you to always know the azimuth position of the module. If you have a separate way to do the encoder then there is no need to go 1:1 on the pulley.
Prior to this year, we (2767) used a VEX planetary encoder stage to determine the azimuth angle. Since the planetary was tied to the actual swerve module via the belt and pulleys, the 1:1 pulley ratio was to ensure that the encoder was reading the actual position of the swerve azimuth (assuming no belt slippage). We ran that way for years and it generally worked very well. However, despite pretty high belt tension, 180 degree wrap and very secure mounting, occasionally we would have a tooth jump which resulted in a wheel being misaligned and poor driving. This would happen when a wheel hit an obstruction on the field obliquely at high speed. To avoid this issue entirely, team 4004 M.A.R.S. Rovers modified the Third Coast Drive swerve architecture last year by putting the encoder directly on their swerve module. They avoided a hollow shaft encoder by using a set of 1:1 gears with one of the gears concentric with the azimuth axis. With this year’s game having the 1" obstructions, we followed their lead and moved the azimuth encoder over to the actual swerve module to avoid the possibility of that issue biting us. We are using the CTRE magnetic encoder but with a longer magnet (K&J Magnetics) which doubles as the shaft of the offset gear. The gear on the azimuth shaft is keyed to a slot in the shaft (slot milled in shaft, key printed as part of gear). Our gears and encoder housing are 3D printed in Onyx, but PLA would work fine. Note that the face width of the encoder gear is larger than the azimuth shaft gear in order to accommodate the positraction travel (see white paper for positraction description).
The white paper will be updated with the details of the 2020 design later this spring. In the mean time, below is a cross section. BTW, also new this year were:
- Wider (1" vs. 3/4") rough tread wheels for improved traction.
- Wider saddle to accommodate wider wheels.
- Falcon Drive motor (R.I.P 775Pro and Super CIMile!) and slightly tweaked drive ratios.
- Slight changes to mounting hub to accommodate the azimuth encoder mounting, adjust belt heights and increase cross section.
in short: no
the long answer: your overall turning ratio for your azimuth motor should give a free speed of ~200 rpm (a little higher is ok), but the reason why many teams have their last stage at 1:1 is so that they can use the motor to read the absolute position of the swerve (often they are using a vp gearbox with a vp encoder, like 2767) . However, as @Doug_Staunton talked about, there is one fatal flaw to this: if you are using a belt, or anything that can skip, and it skips, your positioning is now off. We used a modified stryke force module last year, and this issue would happen almost every other match, and really hurt us. the main cause of this issue is because you are sending power through whatever is reading the swerve module position, rather than passively reading the module’s position. passively reading its position is what teams like 2910 and 2767 now have, which means that there is no resistance torque between the module and the encoder that reads its position. I’d highly recommend passively reading the module’s position, we used it this year, and we’ve had zero problems with it.
On 3419, we’ve gone 1:1 from our azimuth gear box to the module using a Versaplanetary encoder for many years, for all the reasons stated above. We would generally have a tensioner on the belt to ensure low backlash and a low likelihood of skipping a tooth.
This year we did it differently, and it seemed quite promising, although it never got to see an actual competition. We used a NEO 550 on a 25:1 Ultraplanetary as our azimuth gear box, and then ran a 2:1 ratio on the pulleys to turn the module. We measured the absolute position of the module using one of the new through-bore encoders, which are quite nice: https://www.andymark.com/products/lamprey-absolute-encoder
This combination allowed us to keep it all very compact, light, and inexpensive. The ultraplanetary is a very nice gearbox for this usage, although I don’t love the 5mm hex output. We stuffed it into one of these to make it 1/2” hex: http://www.revrobotics.com/rev-41-1450/ . I don’t love the tiny mounting screws for it either, but it gets the job done.
right, but if you know your starting position and your ratio, couldn’t you just do the math to find the position?
I’m going to ask a question that I hope sparks some discussion. What’s the rationale for basing a motor and gear ratio choice on an RPM output given that it effectively never makes more than a full rotation? Shouldn’t we base this on torque and responsiveness (which might be what we’re all trying to do with RPM but RPM doesn’t necessarily make sense to me)?
Also, we also use 1:1 for azimuth encoder. It’s a coaxial shaft with a custom printed housing for the CTRE mag encoder:
I would say that 200RPM is a good starting point based more on how fast can you change the robot’s direction. It takes about 100ms to turn a swerve 90 degrees if geared for 200 RPM (someone check my math!). If the robot is moving at 15fps, that’s 1.5ft to change direction. Our experience is drifting robot/sliding wheels when turning that fast so why go faster (lots of black skid marks on the practice field).
My guess would be because actually calculating the time it takes to rotate 90° from standstill is a much more difficult task than calculating loaded or unloaded steady-state speed. Even with the most generous assumptions it requires solving differential equations, at worst you pretty much have to simulate it timestep-by-timestep. If you know that the motors are well-suited for the job (based on their current draw) then the steady-state speed should be a decent stand in for the “Time to 90°“
Here is the part I don’t understand. Everyone uses 1:1 so that the absolute encoder tells them where the module is pointing, but lets say you have 2:1. the encoder reads 40 degrees, so you know you have actually moved 20. (I know this isn’t how encoders work but you can convert ticks to degrees) in fact, if this was done in the right direction, wouldn’t you get more precision since you would have twice as many encoder ticks per revolution?
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.
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.
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.