pic: GBX-114, Ultralight shifting swerve drive

A swerve drive based off of this one by Bryce2471: http://www.chiefdelphi.com/media/photos/40949?
It is a shifting one-cim swerve drive with speeds of 16.9fps and 9.05fps with losses, or 20.9fps and 11.2 fps without losses. It’s better suited to a cim and minicim combo swerve, which is what I’ll add for the next version.
Currently there are no fillets in the CAD, as each team may have different manufacturing resources. Waterjetting is good, but there are a couple of counterbores that need to be manually machined in or CNC’d.

As shown in the picture, this weighs 6.16lbs. That’s the cim, RS-550 motor, banebots 1:26 gearbox, and all the gears and the module. Most evertying is 6061 aluminum except for the gears in the module itself, which are 1045 steel from QTC Gears. A chassis made with this, minus fasteners, weighs about 29.7lbs. With fasteners, maybe another 1-2lbs.

One thing I seriously dislike about this module is the huge space between the top plate where the cim attaches and the main turning part. However, this allows for later changes to make the wheel up to 3.5" in diameter. Currently it is a 2.5" colson.

I will release the CAD files as soon as I add fasteners to everything. The next version will include an extra cim slot, and the version after that will be manually machinable (although weight will increase significantly).
Criticism is more than welcome.

11fps is a bit fast for a low gear - you’re likely going to run into breaker problems if you get into a pushing match with that if your robot is at the weight limit.

Not sure what I think about pulley setup here. Having multiple belts off of the same CIM is going to make tensioning a bit of a headache if you can only adjust the tension at the CIM. It also looks like you’re really not getting much wrap on one of those pulleys - I’d be worried about that, especially with 9mm belts.

I know the low gear is too fast; it will blow the breaker in an extended pushing match. I’m improving this to hold an extra cim so that the code won’t have to account for it. Swerve drives don’t need to worry about pushing matches if programmed to do so, as they can move their wheels into an X formation to become a wall, or translate to get away from an attacker.

Tensioning is done in two ways: the smaller belt is tensioned simply by moving the cim outwards along a slot. The larger belt is tensioned seperately by moving a pulley outwards, although I’m going to change that to a roller moving inwards to address the wrap issues.
Thanks for the advice!

Any basis for this conclusion? I was thinking without blue nitrile, this was a good starting point.

It looks good! I’m seriously loving the amount of swerve drives on CD right now! I know definitly when I become more confident in my Solidwork Skills, I will reference this model among a ton of others. Keep up the good work!

Very cool! I was also planing on doing a belt shifting version of this as well. I have a couple questions though.
What is the second white pulley on the lower belt for?
Are you worried about it being cantilevered off of a single plate?
Why did you float the drive encoder in the air?
Is the steering encoder absolute?
If so, how do you plan on determining the exact angle of the caster with the gear ratio?
How do you plan on adjusting the belt tension if necessary?

It’s a colson wheel, so the COF is only slightly lower than that of blue nitrile. A pushing match gets the cims up to 60+ amps acording to JVN design calc, so if the drive is really mired down, that’s not good.

The second white pulley was for tensioning the larger/ lower belt, but I just updated the model and now instead am using a plain bearing to tension the lower belt.
The drive encoder is not floating. It’s held in place by some standoffs on a Vex mounting plate.
The steering encoder is absolute. Although it’s geared down, there are still ways to ensure that the angle it’s reading is correct. I’m thinking of hooking up an XMOS or some other lightning fast microcontroller to keep track of the angles and rotations and make it seem like the encoder is directly on the module. Essentially, you count the rotations the encoder undergoes from the start of the match and add add the partial rotation the encoder is at presently, and apply the gear ratio to determine the “true angle” of the module. I could use some 3D printed gears in the empty space above the module instead, but that would add quite a bit of weight and complexity.
Belt tensioning is in two steps. The top pulley is tensioned via a sliding the cim, and the bottom one is tensioned by moving unconnected pulley in and out. The newer model uses a plan bearing instead of a pulley for this.

EDIT: The cantaliever on the drive plate is solved by adding a partial ring made of delrin aroud the main module. It’s not in the picture, but it’s there in the cad. It keeps the module from rocking around.

Update: Here is the CAD file for the newest version: https://drive.google.com/file/d/0BzU34PeNVT0QTFVteGQ4Yjc3QTA/view?usp=sharing. It accomodates either a single-cim or cim+minicim input. If the extra minicim is used, the speed can be bumped up by increasing the top pulley size. Weight per module is 8.92lbs with the minicim, and 6.58lbs without it. The STEP file contains the entire chassis, which weighs 32.22lbs without the minicims and 41.04lbs with the minicims.
These weights include all screws, washers, nuts, bearings, motors, pneumatics, encoders, gearboxes and clips in addition to the module itself. Pretty much everything except for settling dust and the 5mm HTD belts.

To address the belt wrap, I moved the tensioner in closer so that a minimum of 5 teeth are in contact at any given time. I know this is below the recommended 6, but it’s 5mm HTD so a decrease in capacity isn’t bad at all.