The in-wheel swerve shifter!

So I made an autoshifter in CAD using a weird custom dog, parts from the GEM gearbox (ring gear is a measely $10 vs. $100 for other internal gears) modified for this purpose, and a custom wheel made to fit the ring gear.

The way this works:

  1. There is a primary reduction from CIM to wheel shaft.

  2. The shaft is spinning in one direction, say, clockwise. The dog is keyed to the drive shaft and spins with the shaft. It also engages with the hub of the wheel, to direct drive the wheel from the shaft. The dog is “locked” to the wheel due to the acute angle of the teeth. The wheel spins clockwise with the shaft.

  3. There is a collision with another robot and the robot gets into a pushing match. The driver flips and switch, and the CIM then reverses direction- now the wheel shaft spins counterclockwise.

  4. The dog spins with the shaft. However, now the dog is no longer “locked” in place due to the shape of the teeth. Now, the obtuse-sloped side of the tooth contact the like side of the wheel hub and pushed the dog into engagement with the sun gear of the planetary gearset.

  5. The dog “locks” into place with the sun gear due to the acute angle of the teeth. The sun gear spins the planet gears which transfer power to the ring gear. Due to the nature of planetary gearsets, a counterclockwise rotation of the sun gear with the planet carrier locked produces clockwise rotation of the ring gear. This means that the ring gear, which is locked to the wheel, now spins clockwise. Thus, the wheel still spins clockwise after the shift.

Essentially, all you need to do in order to shift is the reverse the direction the CIM is spinning in.

Obviously, this poses the problem: how do you go backwards if you reverse the CIM to shift and the wheel only goes forward?
The answer: you can’t. This is only suitable for swerve drives for this very reason. You have to turn the wheel to go backwards. RS-775 18v are suggested for turning motors.

In order to manufacture the parts in the CAD, you would absolutely need at least a 4-axis CNC due to the weird dog and mating gear/ hub. Not to mention the wheel itself. Because my team lacks the resources to do this, I decided it would be fine to release my CAD of this.

There’s probably a ton of errors in the CAD right now (I’ve only cadded a few of these, and this is the first actual possible swerve module with it) but I wanted to see what the CD community thought of this idea quickly. The CAD is missing bearings, circlips/ eclips (I use the latter), and a miter gear on the primary shaft. Reduction is accomplished with the sprocket for an adjusted 20.0fps high gear and 7.5fps low gear. This is can go down to something like 18fps high gear pretty easily just by increasing the size of the versasprocket. I only had a 34t versasprocket on hand in CAD, but 38t would be preferred.

I use SolidWorks, so if anybody would like the native SW files I have those on hand for the weird dog geometry.

Files in STEP format for download here in a zip folder: https://drive.google.com/folderview?id=0BzU34PeNVT0QUzlVM2dyVzRiT00&usp=sharing

EDIT: Forgot to say, feel free to slam this however you feel. Anything at all. I have designed a ton of swerve modules (upwards of 15) but none of them have been built. So any input at all will help with the next ones.









Its a really cool idea. I would be really scared of the gears teeth shearing off that close to the final reduction of the drive train.
This may also cause major latency in the drive train something that i don’t even know if the shifting could compensate for. Also you could not do on the fly shifting and the complexity of the system is high little lone putting it in the already complex swerve drive. I love the idea tho and think that it may have uses in non drive applications.

Also a RS-540 would work well too, 775’s are over kill in my opinion.

Thanks for the input!
The gears are from a GEM planetary and are all 4140 steel IIRC, so I’m not too worried about the stripping.
Due to the wheels not reversing direction every time you shift, the only thing that the CIM has to fight against to accelerate is the inertia of the shafts and gears, not the inertia full robot like in a normal reverse. I did a small test with an unloaded cim and it would reverse instantly, but definitely something to look into. I think/hope the lack of inertia would reduce latency to almost nothing.
Unless you’re talking about the sheer number of gears, which I have nothing to compensate for.

The reason I said RS-775 is so that you can turn very very quickly to compensate for not being able to reverse the cims to go backwards. Plus, anywhere you can use a 775 power-wise you can use a CIM (you would have 2 left with this drivetrain), except on a versaplanetary (preferred turning gearbox) which requires modifications.

You can’t really do not-on-the-fly shifting technically, because the cim’s turning is what keeps it engaged. :stuck_out_tongue: But in reality you could probably not shift on the fly and be okay.

For latency i meant the time it would take to turn the wheel.

Yeah, that’s something I can’t really address. This uses the minimum number of intermediate gears that is possible with this size wheel.

1717 doesn’t seem to have problems with their gears, but it’s true that the GEM gears have a TON of slop in them. I still can’t figure out addendum mods for planetary gearsets, so for now I’ll stick with this. Definitely something to work on in the future though.

I’m not sure if this would work, but it’s an interesting idea. Is there any reason you have only one planet gear? Are the planets going to be carried by anything or are they just floating? Is the planet arm fixed, free spinning?

If you need an initial reduction from the drive motor, why not just shift there?

I like the idea. My first thought was that this could be better suited to lifts (think 2013 climb) where there has little load when traveling one direction and much more in the other.

Wow, that’s a really cool idea!

I’ll agree with others that it may not be practical for a drivetrain (not being able to shift on the fly, and having to turn the wheels around to go backwards), but I can see this kind of mechanism making it’s way into other parts of a robot!

There are actually 5 planet gears. The way I CAD stuff, I want to put in all the shafts and e-clips before patterning the planet gears 5 times.

So the reduction comes from the sprockets on the wheel and shaft above the wheel. The cim can go directly above the module right in the center of rotation, to remove the need for gears outside the swerve module.

Why can this not be shifted on the fly? Am I missing something here? Keep in mind that this can ony go forward. There is no reverse because I’m driving sun-ring, not sun-carrier in the planetary gearset. This means that the reverse of direction by the cim will only work against the inertia of the drive shaft, not the whole robot.
Here is a good link to learning about planetary gearset ratios: http://science.howstuffworks.com/transport/engines-equipment/gear7.htm
As you can see, the ratio between sun and carrier, which is normally used in planetary gearboxes, is (ring/sun + 1):1. However, this uses a sun and ring mate, for which the ratio is -(ring/sun):1. So when the shaft reverses direction, the wheel continues spinning the same direction that it was before.

If you’re willing to give up direction changes (as this drive does), there is a simpler way to get the same affect.

Run two parallel stages of reduction from the motor to module input with different ratios. Put all of the involved pulleys/gears on one way bearings.

When you drive on direction, power will be transmitted through set A while B free spins and vice versa.

Something I thought of that Aren Hill and I have been debating about for a while.

Interesting, and clever! That would be a good way to do it outside of a swerve or wheel, for something like a PTO. However, this way is a lot more compact if you are using it inside a wheel. Outside a wheel though, one-way bearings would do really well.
I always wondered, how do you get the one-way bearings to spin with the shaft though? Wouldn’t the shaft just slip? Or do you add screw locker or something?

Slip inside the bearing you mean? My team used a one way bearing on our winch this year. We press fit it into a bearing block and press fit a coupler into it. The friction was strong enough to hold everything from moving even with 500 in*lbs of torque on the coupler acting against the bearing.

Would you happen to know of a source for one-way bearings that fit in typical FRC drives and are rated for the loads we see?

McMaster has some. You would need to do some load tests though; they’re rated pretty low. For that reason they would probably be on the CIM shaft (they come with 8mm bore)

Wow, that’s pretty buff!

I would run 2489K23 on the CIM and 2489K5 on the module input.

Both have quite comfortable FOS as a CIM stalls at ~ 1.7 ft-lbs.

This looks really cool. It looks like it could work well on a 2013 climber, where you’d want to deploy quickly, but raise the robot with lots of torque.

What happens if you’re going slowly and somebody pushes your robot from behind? Instead of the wheels driving the motor to go faster, the dog will back out, but it won’t engage with the other side because it’s going the wrong way, so the dog will be bouncing off the two sides until you speed up the motor or reverse direction.

It can’t shift on the fly because even if the output direction doesn’t change, reversing the CIM will still slow the drive down to zero and then go back up to speed. The motor has to fight the inertia of the drive system when reversing input direction, and this takes time at which point you aren’t moving.

Like I said, the motor only fights against the drive shaft. That’s just a couple miter gears, two 3" shafts, 2 sprockets and a gear. The CIM will instantly reverse unloaded, so even with the above it’s not a lot of inertia.
That would be something that would be debugged and found in testing.

Interesting example. If a fast robot pushed you, the dog would instantly lock into the other gear, be it low or high. Then as you said, it would probably bounce around. I would want to test this too to see for myself the ramifications.
You would have to have code to debug this situation, probably with current sensors to see if the current gets too low, signifying a robot is pushing you. Then the cim would reverse direction.
In any case, then you could just shut down the cims if it continues (it would be a pretty obvious strategy) and you’re going in the direction you want to anyway, but faster. So that situation would be useless for the other robot.

Would you then have to put some sort of brake system on your roobt? or would you simply have to spin the wheels the other direction to get them to slow down?

Why are you ignoring the load of the robot and the drivetrain itself? Even with your shifting coupler, it will only disengage as the motor attempts to turn the shaft the opposite direction. Until this is disengaged, as the motor slows the drivetrain slows, and the load of the drivetrain is placed on the motor.

CIMs do not “instantly” switch direction under zero load. Quickly, maybe, not instantly.