pic: Small CIM in wheel swerve

I wanted to see how small a swerve could be if it was a CIM in wheel design, but using a mini CIM. Ill admit that this design didn’t turn out as well as I was hoping, so I haven’t filled in some of the details. Even still, I though it might be interesting enough to post. Let me know what you think about it, or if you have any questions.

It’s about 4.5’’ tall, and inventor says that it should weigh 4.6 lbs per module.

4.6lbs per module? I think you’ve finally made a swerve that can be lighter than a WCD.
Much applause.
Is the two-plate design lighter than just flipping the motor over and using a planetary gearbox?

EDIT: Is that a custom gear on the bottom?

DOUBLEEDIT: Oh wait, MiniCIM. Dang, that was almost the dream.

Are you certain your materials are set correctly? A mini CIM weighs 2.16lbs according to VEX. If they are set correctly and that is in fact how light the module is, than I must say, very impressive.

Thank you. This was mostly a design experiment for me, but I suppose it could be useful in a game like this year where a lot of weight is needed for the manipulators, and maneuverability is important, but pushing power is not.

Is the two-plate design lighter than just flipping the motor over and using a planetary gearbox?

i’m not sure about lighter, but I thought it would be a shame to put such a tall gearbox on such a short swerve module.

EDIT: Is that a custom gear on the bottom?

Yes. Several of the gears are custom so it would require access to a good laser, water jet, or wire EDM.

DOUBLEEDIT: Oh wait, MiniCIM. Dang, that was almost the dream.

Maybe one day.

Thank you, the mini CIM is accounted for, at 2.16 lbs. I’m pretty sure that the materials are correct, but like I said, there are some details that aren’t in the CAD.

What motors turning the left right motion? Pg or 750 maybe?

In the CAD, it is an AM-912, but in reality, I would probably use a banebots RS 550.

If you used a worm gear for steering, it seems to me that you could orient both motors horizontally and get the module height down to the wheel diameter. You’d also save some weight on a second gear stage at a bit of loss of steering efficiency. You’d need slip rings for the drive motor since you couldn’t run the wire out through the rotation hub, which might eat up the weight savings.

Also, what is the light colored gear to the lower right of the main rendering? I don’t see what else it engages, and I also don’t see it in the reflection.

Great work, would you be willing to share STEP files so we could take a look?

From the looks of the reflection, I would say that it’s paired with another pinion underneath the bottom support plate via a live axle, which in turn is what engages the great big ring gear that goes around the perimeter of the module.

That makes for a 3-stage reduction in total, so I am inclined to agree that a worm gear would be a viable option here.

Thanks, Skywalkar - I see it now. The reflection plane must be tilted down as it approaches the viewpoint (or the vertical on the module is tilted away at the top). I thought it strange that the dark gray gear did not engage with anything except to pass through to the yellow gear below the lower plate.

Really nice concept once again.

Are you using a Silver Thin Bearing to support the the pivot assembly?

The planetary drive inside the wheel is a great idea, are there two stages there for ~9x reduction?

This is what I’m most curious about, what kind of speeds are to going to get out of these? I’m sure there’s an encoder mount somewhere, but where is it? Very, very impressive design.

With a large steering gear like that you can’t use an absoule encoder.

Team 141 at championships had a similar large steering gear setup. They used an incremental encoder to count steering input revs, but also had a pivot extension that triggered a proximity switch to calibrate the nominal forward position. Really elegant and beautifully machined swerve drive. They used a Kaydon brand bearing, very similar to the Silverthin ones. I had the pleasure of talking with the 141 students and mentor for quite a while, really an exceptional team.

It appears there’s an absolute encoder on the top of the entire module, likely connected by bent polycarb like 2451 and 3928 before them.

On 696, we had a large 84T 20DP steering gear, and a 1:3.5 ratio between that and our MA3 absolute encoder. That is, the steering encoder would pass through 3.5 rotations for every one rotation of the swerve module. We had to physically set the wheels pointing straight at the start of each match (which is probably good practice anyhow), and there was a good bit of math and code involved, but we were able to very reliably track the position of our wheels at all times, resulting in fine control and operation.

Was it easy or friendly to do it this way? No. Is it possible? Yes. Would we run anything other than a 1:1 ratio to an absolute encoder again? Maybe not. It’s kind of a pain. We likely will look into using a zeroing sensor and incremental encoder next time if we cannot maintain a 1:1 ratio with an absolute encoder.

If your sample time is fast and stable enough that the encoder could never turn 180 degrees from one sample to the next, then “all ya gotta do” at each sample is assume the encoder turned through the shortest angle, and keep track of zero crossings.

Funny you say that. That was the original plan, but Java’s timer tasks (as mentioned by 254) are slightly broken on the roborio. We had latencies in code of up to 200ms. We ended up using the FPGA’s analogTriggers to keep track.

Since there’s really never a need for analogTriggers save for this one strange case, that was broken too. Thank god for the fantastic people at WPI that got it fixed so quickly.

I know sanddrag said that it worked well enough at competition, I have to say the headache caused by this is greater than he may have noted, and took a lot of time out of the season. It’s generally just not a good idea to do incremental sensing of anything if it is at all possible to have absolute sensing. Zeroing sensors are a must.

If you embrace incremental, then it can be a huge time savings.

We never have to manually zero sensors, there are no magic numbers in code, and we know we can replace a sensor/system at any time with no new work required.

Every position system 973 has ran all the way back to 2012 has been on an incremental sensor that assumes a zero at start (plus sometimes a manual or automated routine to hardstop zero). We always mean to add the zeroing sensors, but never do as the functionality isn’t needed.

Here’s the code (I think). Haven’t tested it:

Let A be the encoder angle reading in degrees (0 to 360 clockwise) at the previous sample, and B be the encoder angle reading in degrees at the current sample. Then:
D = B-A;
D -= 360*floor(0.5+D/360);
if((D>0)&&(A>B)) turns++;
else if((D<0)&&(A<B)) turns–;

I would like to use a worm gear, but I have no idea how to make a large custom worm gear, and I assume that a COTS gear that large would be incredibly expensive. Perhaps worth looking into though, since this was just a CAD experiment anyway

Thanks, right now it uses a bomb squad style slew bearing.

I kept it to one stage in this design, but it’s likely geared too tall for most situations. It’s a 5.33 to one reduction on a 3.5’’ wheel.

We have run an incremental encoder with a homing index in the past, and would probably never go back… It’s a real pain, and the drift robs a lot of a swerve’s efficiency.

Correct, although I’m still debating how the wire routing will work…

You also need to have a good home position. Which would likely involve putting the swerve slightly to one side of “Straight” before every match, so that it’s “zero” would be the real zero of the swerve, to begin with.