This is the swerve drive model that I created for my FRC team for future use hopefully. This is our first time working on swerve drive, but our programmers have experience with mecanum.
The model consists of 2 key components; the swerve drive pods and the dual speed gearboxes. The dual speed gearboxes are a bit on the experimental side as they do not use the traditional dog gear to shift. They instead rotate gears to mesh and unmesh on the fly. The gear ratios are 5.33 in high gear and 10.88 in low gear. Two gearboxes are put together to achieve shifting with a cylinder between them. This allows for half the needed cylinders while still having each wheel independently driven. A SRX Mag Encoder is attached to the output shaft. The output shaft then drives the swerve pod via chain and sprocket.
The swerve drive pods use a coaxial drive, with the drive power running inside the pivot shaft. The pivot shaft is a hub that clamps on a 1" x 2" rectangular tubing with thrust bearings to lower the friction. The pivot motor is attached to the 1" x 2" tubing and drives the hub with gears. The drive shaft comes to a bevel gear to rotate the power transmission by 90 degrees. The wheel is driven with a chain and sprocket, allowing for a simple change in gear ratio if needed. An electronics assembly has been added, but is still a work in progress.
5.33 high gear and 10.88 low gear ratios
4" High traction wheels
48ish pounds as measured in Inventor (still working on accurate weight calculations)
Using the JVN Motor Calculator, I have 14.13 ft/s in high gear and 6.92 ft/s in low gear
Is there anything missing in my model? Any points of failure? Any suggestions on gear ratios or speeds? Any improvements that you can think of?
Thanks for all the feedback!
-Reed Nowling, GalacTech Robotics Engineering Design Team Leader
I see the thrust bearings, but I don’t see any radial bearing/bushing to keep “Pivot Module Bottom” from rubbing against the frame. Is there something I’m missing or are you ok with metal-on-metal contact there?
Also I’m a little skeptical about the on-the-fly gear meshing. It definitely could work, but without a synchronizer like in a car transmission I could imagine a fast-moving gear crashing into a slow-moving gear and shattering. Just something to keep in mind.
Interesting take on a swerve drive. Using drive units separate from the main modules used to be a norm, but now people like to place the two closer together to save space. I would recommend that in your case, as your swerve is currently quite large and has a lot of unnecessary shafting.
I really don’t like crash shifting. Your gear mesh is highly dependent on how accurately your cylinder/linkage move, not to mention the huge gear tooth stresses from having two different-speed gears mesh. What’s wrong with just using a ballshifter/dogshifter, or no shifter at all? Any of those will reduce weight and footprint, not to mention complexity.
That being said, I like the way you’ve set up the gearbox. All the positive shaft retention everywhere is nice too.
Your caster box/module looks really solid, except for the washer on the horizontal bevel gear. Washers are not accurate in thickness, and in your case it also looks like it might rub the outer race of the bearing.
Why are you cutting away so much of the large turning gear?
I think your encoder stage should be fine, as long as you do the right math to convert it to true angle.
LOVE the wires and chains in CAD. looks very nifty.
And lastly: what made you choose this design over a bevel-beside-wheel swerve? For the amount of machining you’re doing, that might end up a lot more compact and lighter for you.
With some simple gear ratio math I think we should be able to get the right angle.
I felt that with the small amount of rotation happening within that part (no more than 180 degrees at a time) I felt that just using a bit of lubricant would suffice.
I found my inspiration for both this transmission and swerve from this very video.
I decided to make the two separate as I wanted a simple swerve pod that would be able to be replaced in a short amount of time, and be easy to manufacture. I feel that making them separate will give more flexibility at times of failure. I also wanted a dual speed transmission on the bot, and I came up with few good ways to do such within each pod.
My team used dogshifters this year and I felt like the mesh speed was not optimal. I (as the competition driver) had to back off the throttle to shift between gears, and I would lose a lot of momentum. I am hoping this will provide on-the-fly shifting, possibly even with a choice between manual and auto shifting. As for using a shifter, this was more of a personal preference. I have been the driver for 3 years for my team, and I am one of the more aggressive drivers (I pushed a robot up on its back wheels and all the way across the width of the field a few weeks ago), so torque is a necessity. However, my team typically picks a position that requires high speed and maneuverability on the field. A shifter seems to be the best choice.
Any suggestions to replace the washer?
I think the gear you are referring to (the big gear on top of the 1" x 2" tube) is a versa gear from Vex. So it comes with the versa key slots in the center.
Thanks! I have been working a lot on using chains and wires in assemblies this off season. I still am learning a lot about using these and this was one of my better uses of it.
I am not quite sure of what you are referring too about bevel-beside-wheel swerve. I think I have an idea of it, but could you explain further or link a picture?
I will give you that the SRX libraries and CTRE sensors make this easier by overflowing and counting ticks and keeping them across reboots but it’s not as simple as multiplying by a gear ratio. You also need to account for the angle over time and deal with different offsets for each module. Not to mention that least-turn-angle is a lot easier to implement without all of this.
Also, keep in mind the processing power of the controller and the fact that you are multiplying calculations by 4 for all of the modules. Swerve is CPU intensive and anyone who says otherwise isn’t logging that data or paying any attention to it. Also keep in mind the limitations of the closed loop calculations that you can do on the Talons. PID is a lot easier with 1:1.
There is a reason other swerve designs incorporate 1:1 turning encoders. Teams went crazy in 2015 trying to figure out how to do it for the AM Swerve modules. Triple Strange just posted a design that had some not-so-simple machining to do it. Check out the 221 site and you’ll see 1:1 for turning on all of their designs and crab chassis. There is a reason for this. This is a bigger headache than folks seem to think.
The scheme I was imagining in my head involved using a hall effect sensor to zero the rotary position, following which pure quadrature/index would be used to find angle by dividing by a gear ratio. If you’re using absolute positioning instead of quadrature, I can see a lot of problems, but as long as you either zero it via magnet or via index signals, I don’t quite see the problem. Is there more to it than that?
To OP: If your dog shifting was not able to work on the fly, were you using a cylinder to shift? If so, then ball shifting should work well for you as it requires less force to shift.
Agreed. This drive base is quite bulky and could prove to be an issue when you need space for mechanisms. The only time Team 696 made swerve was in 2015, where we also needed to hold totes inside the robot perimeter to work better with the CoG. Many teams that year also kept the game pieces inside of their frame for similar reasons. It’s not too hard to design things that are small and compact these days. There are great resources of teams that have been making swerve for years… I just wish 1717 was still around to be pushing the limits along with everybody else
This also seems very heavy. Chain. So much chain. Again, that used to be the norm, but things have changed with time. Of course, it matters where you were going with this design, and how you wanted the layout to be.