Quarantine boredom is starting to really set in, so I got around to doing a swerve drive. The primary goal of this design was to make something a little lower-profile (vertically) than the SDS swerve while still being perrty robust. I also included that neat little section above in case anyone was interested in getting a closer look at how it works. The weight in CAD is 5.6lb, which isn’t great, but also isn’t terrible.
If I had to go back and make changes, I would likely flip a few bearing flanges. Currently, the design requires on a handful of press fits to permanently retain some bearings, so flipping them would make it a little easier to fabricate. I might also split the encoder gear on the pivot and the base plate which mounts it to the rest of the pivot into two parts in order to remove the overhang and make it easier to 3D print.
Is the hole pattern through the azimuth gear something that comes COTS, or are you machining that? It looks almost the right size to work with versakey…
EDIT: Oop, azimuth gear is 3DP, got it
I’m just waiting for someone to use the Falcon vent hole as a structural member now
The original plan was to terminate the tube before it got deep enough into the corner to intersect the azimuth gear. That’s the reason why the standoff on the outer corner is so far out - it can snug up against the corner of a bumper. You could definitely try, but you’d have to cut out almost the entire inside face, since the standoffs on top of the azimuth gear also interfere with the extrusion.
I don’t understand why you would want your Falcons pointed down at near-ground-level. If there’s a bump or something you have to drive over and you approach it from the wrong direction, boom there goes $140 and that match. With the motors weighing less than 1 lb/piece, putting them at the top won’t raise your robot’s CoM significantly (probably not even noticeably). I get the desire to leave clearance above the swerve drive for other manipulators to sit above it, but it just seems like a hugely unnecessary risk to me.
It might not be great for games with bumps, but I could see a huge advantage in a game like 2017 where you want to maximize hopper space and there’s relatively little risk to the motors.
Sure, but field debris still exists even in games with perfectly flat fields. We had three different robots lose vise-grip wrenches on the field in two competitions this year. Even in 2017 if that happened and you accidentally drove over it you’d be seriously endangering the relatively fragile electronics on the back of the Falcon 500. And you’d only be saving one or two balls worth of space for each module. To me it just doesn’t seem worth the risk.
At least for the steering motor, perhaps you could rotate the motor ninety degrees and use a worm gear rather than a pulley and a spur gear; this would let you keep the low peak height while keeping the motor at a safer altitude. The same might also work for the drive motor using bevel rather than worm gears.
I’ll note that there are many ways to mitigate this. At present, the ground clearance is 1.4" to the floor and in my opnion not quite at ground level; switching to 4" wheels could get you an extra inch of ground clearance and moving the wheel outside of the azimuth gear would net you another 0.75". At that point, one could easily shift the 2x1 to be on the opposite side of the bottom plate and have the Falcons be as safe as they could ever possibly be.
Alternately, you could switch to NEOs or space the top plate up further to bring the Falcons within the height of the robot frame. These are all solvable problems, so I don’t think it’s necessarily a reason to axe the entire arrangement.
If a team were seriously implementing the design in-season, they would (hopefully) do the necessary testing and tuning to effectively work around the issue. Depending on the circumstances and the game, it might be that this design would work wholesale.
I wouldn’t worry too much about ground clearance unless the game dictates different. Our motors hang down like this and not a problem. If the motor clears, the motor clears. For us, the belly pan is almost always lower.
But, you would not have the same issue with a NEO. The total height of the NEO is 2.3", so assuming those are 1/4" thick top and bottom plates, that would mean that a NEO would only be 0.050" below the bottom of the bottom plate. And of course the cover on the NEO is not sensitive electronics. So this design might be really awesome for NEOs to meet the goal of a “low profile” swerve module.
If you thinned out the top plate by 0.050" (pocket from the bottom of the plate) where the motor mounts, you could get the motor flush with the bottom plate. And a deeper pocket of half the top plate thickness (0.125") would put the lowest point of the motor above the bottom of the bottom plate.
One thing to think about relative to the absolute encoder is that the total backlash between the position sense (the encoder) and the driver (the motor) will affect the deadband of the control loop. The backlash in the encoder is part of that so reducing this is good.
But, the backlash and deadband between the position sense and the driver can also be eliminated completely if you use the built in encoder in the motor itself instead of the absolute encoder for the control loop. You still need the absolute encoder to detect the initial position, but once you have the initial position established, you can use the motor encoder to do all the steering control from that point on. And the steering control can be done in the motor controller itself which has a much shorter control loop time and therefore can have stable control with a much faster steering speed (lower steering gear ratio) which could allow you to reduce the size of the module gear and potentially make the whole assembly a little more compact.
Wouldn’t just using the motor encoder after getting the initial position with the absolute encoder make it hard to drive straight? Would you need to use both continually to be accurate?
This doesn’t really fix anything, you’re going to end up having a similar constant error due to the backlash in the encoder gear while making the initial reading. Often you’re going to have more backlash in the motor to azimuth gear/pulley train which would go unobservable, so I would recommend sticking with just increasing the DP of the encoder gear.
In this day and age, it seems like all swerves are slightly modified versions of each other. It would be interesting to follow the trail of inspiration all the way down to the very first swerve.
