1640 has a swerve wiki that’s pretty good that covers the iteration of their modules, with some reference photos of 1717 as well. CD Media also has photos of swerves galore. If I was to try and outline from zero to “as good as I can explain it” though, here’s the answer:
The concept of swerve as you know it is what used to be referred to as “unicorn swerve”. Capable of simultaneous translation (moving in the X/Y plane that is a floor) and rotation (relative to everything else.) it’s called a holonomic drivetrain. There are other holonomic drivetrains such as X, killough, or mecanum, but all of them (generally) lack the traction to accelerate compared to traditional tank drives.
The core requirement of modern swerve is being able to absolutely command the angle of your wheelpod (a wheel and gear setup or wheel, motor, reduction, etc. and a slipring) This is typically accomplished with the use of encoders (but lose absolute heading in the event of a power outage) or potentiometers (usually have limited rotations). Otherwise, you have no way to accomplish the math of producing a given wheel direction for a given input vector. For this reason, controls integration is essential. You may not strictly need a sensor on your propulsion motor, but you definitely need one on your steering motor.
The math for swerve is built-in to WPILib and has examples if you’re curious, though it lacks the vendor-specific implementations (for using sensored brushless motors, but the concepts apply still)
A Side Note On Control
Some teams drive their swerve in what’s called ‘field oriented drive’, where the desired vector on the stick is absolute to the field, not to the robot. If I push the joystick of a robot to 9-o-clock on a non-field oriented robot and it’s already at 9-o-clock, it’s likely to head to 6-oclock. But if the robot is field oriented, and you know what angle the field starts at, you can command the robot to head towards the top left of the field.
As to designing and building one, there are a few ongoing metas observable through the SDS and WCP swerves available for sale. In the past, some teams have tried slipring swerve, where the motor controller is inside the wheelpod assembly. This allows for infinite rotation (same as coaxial), but effectively caps how small your wheelpod can be. Looking at WCP and SDS swerves, as well as a plethora of historical swerves, they’re majority coaxial, where two concentric axles rotate and transfer the translational power to the wheel.
The same concepts that apply to intake design also apply to swerve, in the theory that to get the same surface speed on the roller (wheel), a smaller wheel requires a smaller reduction. For this reason, it often makes sense to run swerve with smaller wheels, to avoid needing a massive reduction.
Some Design Information
I’m no MechE, and very novice at CAD, but there are some key takeaways based on the modules sold in the modern era you can take away.
- Shifting is a lot of work, and not really done. In 2012 1717 had a shifting drivetrain but I don’t personally see the need in the brushless era.
- There are torquey, low cost combos that make steering significantly easier than it used to be. You don;t need to use a dated 550 or use a 775pro on turning, the NEO 550 and an Ultraplanetary get you a fairly high reduction in a narrow, compact package, and a sensor for rotation to boot. Just be sure to be able to absolutely align the robot’s pods before turning it on and spec a reasonable effective reduction for steering.
- Using a larger size motor allows you a smaller yet reduction in turning components, and the net weight of a larger, lower-RPM motor may be lower than the weight of a smaller but lighter motor plus reduction. (do the math!)
I likely made some mistakes but I hope this was still informative and at least gets you into the ballpark of thinking about the complexities of swerve! Practice and iteration makes perfect (and never in season )