I wanted to share the swerve drive module that I have been working on. My goals with this design were to make it compact, easy to use, configurable, and hopefully tough enough to survive a FRC season.
It uses a 4in versa wheel and the gearing is at 8.6:1 for the CIM version and 28.9:1 for the 775Pro version. The ratios are easy to change using VexPro gears. The weight is currently at 7.81 pounds for the CIM version and 6.65 for the dual Pro version.
The 2 pulley/gear parts shown in green will be 3D printed, probably out of polycarbonate. The bevel gears are made using COTS gears that are available from SDP/SI. The main steering bearing supporting the rotating module is a 1/4" section Silverthin or Kaydon bearing. All of the custom machined or modified COTS parts are designed so they can be easily machined on a Tormach PCNC 440.
Lots of credit goes to Aren Hill for his swerve drive designs from which my design gets a lot of inspiration and borrows a lot of ideas.
Looks really cool! 2 775pros and a bag per module seems like a lot to me (not many pdp ports left), but the designs look really cool! One question- what is the purpose of the second gear that has a little yellow thing off the top? What is the yellow thing? Looks kind of like an encoder shaft, and if so I am curious why you opted not to use the Versaplanetary Integrated Encoder for your turning.
I really love how space efficient your modules are, and love the design! Great job!!
BAG motors have a much lower RPM than the 775pro, thus requiring less of a reduction to have a module that turns reasonably. This can potentially save weight and such depending on how you treat it.
The little yellow thing with a gear on it is one of the US Digital MA3 absolute encoders available from AndyMark. The primary reason I choose not to use the Versaplanetary Integrated Encoder was because the output shaft of the Versaplanetary is not a 1:1 ratio to the rotating part of the module. The way it is geared, the steering encoder is a 1:1 ratio with the rotating module. With the 1:1 ratio, the output of the absolute encoder will directly correspond to the steering angle of the wheel. It just makes it a little bit simpler to program and eliminates the need to have the modules pointed in a certain direction when the robot is turned on or something to that effect.
A 775 can be used as the steering motor. It fits fine and you should be able to get the reduction need with the 2 stage versaplanetary and the 3:1 from the toothed belt. I just though it would significantly overkill power wise.
We actually used a 775pro over the BAG this year and ran it at 6-8V. So there isn’t that big of a difference between the two. If anything at 6V the 775pro is @ 9-10k rpm. I only see reduction mattering if your making a custom steering setup and want it to be more compact.
With the Vp’s your going to have to do a 2 stage reduction and at that point you can achieve whatever gearing you want from 12:1 to 100:1! So your not gaining anything using a BAG over a 775pro and vice versa (maybe weight?)
If you turn the module while the robot is off, the encoder cannot keep track of the true angle of the module. If the ratio is 3:1 for example, turn the module 1/3rd of a rotation while the robot is off. The absolute encoder will still report zero, but the module will be in a majorly different position.
Typically a hall effect sensor can be used to zero the module, and the quadrature portion of the integrated encoder used for rotation tracking to be gear-ratio independent. I would still do this with absolute encoders, as I’ve had issues with them moving for one reason or another before. I am 100% certain somebody will chime in with a “but that never happened to us! You must have done something wrong” and I agree- I’m sure that it’s possible to do that. But it’s not guaranteed that it’ll work. The integrated encoder with a zeroing mechanism is hard to make fail, by comparison. Just make sure you always trigger the hall effect in the same direction or hysteresis can throw you off.
This is 100% correct and is the main reason I choose not to use the VersaPlanetary encoder (or any absolute encoder turning with the VersaPlanetary output shaft).
When you turn the robot on the VersaPlanetary encoder would know the absolute position of the versaplanetary output shaft. The problem is that the module will be at 1 of 3 possible positions. Without an additional limit switch or encoder or something to know which of the 3 possible positions the module is in, you will need to make an assumption. An example of such an assumption would be that all the modules are generally pointed in the forward direction.
I don’t want to add the complexity of an additional sensor, and I also don’t want to rely on the drive team having the wheels facing a certain direction when the robot is placed on the field. That’s why I choose to have a single absolute encoder 1:1 with the rotation of the module.
This is also very easy to achieve with a passable limit switch. (basically the button is pressed as a certain spot on the module passes it, but allows the module to continue past it in both directions.) Always zero it moving the same direction though to account for even the slightest mechanical slop.
I think you might be underestimating the 775 pro here. I think you might also be underestimating the impact of using 12 motors on a drivetrain.
I’d suggest you compare the current draw and the max torque of these two modules at a similar wheel speed. (That methodology because you’ll never hit top speed, but you can use that torque to push.) You might find that one of your modules is twice as powerful as the other, but impractical on an electronic level
Wouldn’t this make your robot sit on the field for the first couple of seconds of autonomous while the wheel modules all spin to their home sensors and rotate the chassis a variable amount while doing so? Or do you home them after powering on the robot and before you set it on the field? What happens when someone is in a hurry between finals matches and forgets to perform this task? We found absolute encoders to be quite effective and error proof. Yes if they come loose you will have issues. But the same goes for the screws on the limit switch coming loose, etc.
Great design by the way, I hope you build it. Has any team actually ran an 8x 775pro swerve yet? I wonder if the amount of burned out motors would be drastically reduced by lowering the voltage to each motor. I heard rumors that a lot of teams running single 775pros on their swerves burned up quite a few motors this year. We posted a CAD file for a dual 775pro swerve last year but I doubt we will ever build one. I could see a high speed race track game, like Overdrive, maybe making this worth while. So long as the robot mechanisms needed to play the game could be designed to use only 4 or less motors.
Admired your swerve and driving this year. Question: Why did you use absolute analog encoder with separate gearing vs. a VP encoder in the VP gearbox? (which would seem to be easier to implement?)
The ideal is always to have an absolute encoder at 1:1 with the module’s rotation, since it makes it easier to program and absolute encoders remember their zero even after being turned off (if I remember correctly).
Very common question. It certainly would work to use the VP integrated encoder. The VP integrated encoder even outputs an absolute position signal just like the encoder we are using (US Digital MA3).
The reason why the VP encoder is not ideal for this design has to do with what it is measuring. The VP encoder would be measuring the angular position of the VP output shaft. Because of the gear ratio (of the belt) between the VP output shaft and the main rotating part of the module (in this case it is 3:1), for any given VP output shaft angle there are actually 3 possible steering angles. There are 2 obvious solutions to combat this issue. One solution is to just simply have the wheels pointed in a general direction when the robot is powered on or enabled. You can then make the assumption about which of the 3 possible steering positions the wheels are starting in. The issues with this solution is that every time the robot is either powered on or placed on the field you must make sure the wheels are pointed in generally the correct direction. If this is forgotten, there is a good chance the robot isn’t going to drive correctly because the steering of each wheel is likely to be off by some multiple of 120°. Because of this risk it was decided that this solution would be unacceptable for us. The other obvious solution would be to add an addition sensor to each module so it could either home, or at least know what general position is was starting in. The additional sensor would be added complexity, and if the steering needed to home at the start of the match it would eat into valuable autonomous time.
We felt that gearing the steering encoder 1:1 with the rotation of the module was the simplest and most reliable solution from a mechanical, ease of use, and programming stand point.
