Fixing AndyMark's Swerve & Steer Module Problem

Team_288 · February 9, 2015, 10:56am

Team 931 decided that this year’s game needed more freedom of movement via the drivetrain. We researched and purchased four AndyMark Swerve & Steer Modules http://www.andymark.com/product-p/am-3009.htm

After reading their website and calling to talk to and expert we decided to use an absolute encoder to give us better wheel tracking. So we purchased four Absolute Encoder with Cable (am-2899) http://www.andymark.com/product-p/am-2899.htm

We then realized that they didn’t come with the pinion that they needed to engage the drivetrain and thus purchased four Absolute Encoder Gear for Swerve & Steer (am-2396) http://www.andymark.com/product-p/am-2396.htm

We went along very happy for a while installing them and assuming the best. Assuming that we got the parts that would work as described. After our programming team struggled for a couple hours unable to get them to work correctly we started troubleshooting / investigating and discovered that AndyMark had made a fatal flaw in their design. They had designed for, recommended and sold 12 tooth pinion gears that were to be installed on the absolute encoder that had three pre-drilled mounting locations on their Swerve & Steer Modules. The Swerve & Steer Modules actually used a 40 tooth gear to rotate the wheel 360 degrees thus making the 12 tooth pinion functionally useless.

We needed a solution and fast. This was on Friday the 6th of February and the end of the fifth week of build season. We didn’t have time to order the correct pinion; nevermind the fact that the correct pinion with 1/4" hole and set screw did not exist on AndyMark’s website or any others that we could find.

After a night’s sleep and much debate and arguing we settled on a plan of making our own pinion. Since the pinion has no real load except to turn the tiny shaft of the sensor we didn’t need a metal gear; a plastic one would work just fine. We have both a 50 Watt CO2 Laser as well as one of the new Ekocycle 3D Printers that first gave us.

We decided to go both routes. We used AutoDesk Inventor and had it create a 40 tooth gear using the proper specs from a 40 tooth gear http://www.andymark.com/product-p/am-0178.htm from AndyMark’s website. By using the proper Diametral Pitch, Pressure Angle, Number of Teeth and Pitch Diameter we were able to replicate the gear profile quickly. Then we downloaded the CAD STP files http://files.andymark.com/CADFiles/am-3009+Swerve+%26+Steer.STEP for the Swerve & Steer Modules and used it to “borrow” the profile of the 12 tooth pinion. We created an assembly file and put the two gears together and then cut the profile of the small gear out of the large gear. We then offset (oversized) the profile of the 12 tooth pinion by 15 thousandths (.o15) so that the pinion would fit inside of the plastic part that we produced.

We struggled with creating a DXF file that we needed to cut the profile on the laser and so we proceeded with the 3D Printer. It took an hour and a half to 3D Print one of them with the printer set to make the part “almost solid”. The first try was perfect and the 12 tooth pinion fit perfect and snug into the plastic gear. We decided to do it that way so that we would not have to rely on a set screw in the plastic part to hold onto the encoder shaft.

We held the 3D printed gear onto the 12 tooth pinion by using a pin prick punch to burr the bottom of the 12 tooth gear so that the plastic gear could not slide off the metal gear. It would be held in place by the set screw at the top of the 12 tooth gear.

We then located the new encoder position by using a 1/4" transfer punch and holding the plastic gear in place while it engaged the gear from the gearbox. We did not need extreme precision we just needed it to rotate in sync with the motors.

This worked very well and we believe that the 3D Printed gears will last for the entire season. We will have some backups of them in case of failure.

I have attached photos as well as files that will help you solve this problem.

Thanks,
Charlie Blair
Mentor/Coach FRC Team 931 Perpetual Chaos
Head Coach FTC Team 288 Spare Parts

40 with 12 cutout with .015 tolerance.ipt (660 KB)

40 with 12 cutout with .015 tolerance.ipt (660 KB)

Tom_Line · February 9, 2015, 11:35am

Wouldn’t you have been able to count the revolutions in code and make it work that way? I would wager that is what Andy Mark expected you to do.

It’s not all that different from needing a scaling factor for your drive encoders or for any other sensor. I understand it would be more convenient if one revolution of the module = one revolution of the encoder, but having one revolution of the module be more than 1 revolution of the encoder actually makes your measurement system more accurate.

Ether · February 9, 2015, 11:54am

marshall · February 9, 2015, 12:10pm

I’ve been wondering how a team would go about fixing this after I saw the part being introduced. Thank you for sharing this! Good work!

Team_288 · February 9, 2015, 3:32pm

Yes, there was an option to fix the problem with programming. This was not an ideal solution because this would mean 3.3 rotations of the sensor per wheel revolution. This means that you would not be able to “zero” the wheels automatically on power up. You would have to put the robot on the field with the wheels pinned and then turn on the power so that the robot knows the exact position of the wheels. If you ever had a power loss during a match you’d be in trouble because your wheel positions would likely be messed up.

AndyMark did not mean for it to be that way. I spoke with Danny Blau from AndyMark before ordering the absolute sensors and he explained in detail the way they were “meant” to work. They were intended to be ABSOLUTE, meaning you always know the wheel position.

Optimism · February 10, 2015, 11:08am

Team 2468 here,

We also solved this problem of steering direction by adding an absolute encoder.
We 3D printed a gear to be 1:1 with the steering module and meshed it with the gear driven by the PG71.
Our encoder is an absolute shaft encoder. We calibrated once by storing the value of each encoder in a file on the roboRIO when the wheels were all turned correctly, and now we read that file in the code to know which direction the wheels should face as forward.

A photo of our 3D printed gear on the swerve module is attached.

Team_288 · February 10, 2015, 1:53pm

2468: How did you attach your 3D printed gear to the shaft of the encoder?

We centered our encoders manually before giving the robot to the programming team. First we pinned the wheel in the “zero” or straight forward/reverse direction. Then we powered up the absolute encoder and hooked up a voltmeter to the output of the encoder. We turned the encoder until it was at very very close to 0 volts (most of them were at 10mV) then we installed the gear and locked it in place. The play in the gear translated to the wheels being in their “zero” position and the encoder going from just above zero to just below zero volts. This allowed us to give it to the programming team with no need to correct for the encoder.

Your method seems like a much easier hardware solution.

BTW: It’s always great to see other teams using aircraft Clecos to build their robot. We use them on everything! We’ve even sent the bot onto the field held together with them temporarily.

Optimism · February 11, 2015, 12:32am

We used a set screw to secure the 3D printed gear to the shaft of the encoder. The printed gear isn’t flat to allow for a better mesh with the swerve module gear since the way that we attached the gear, a flat gear doesn’t mesh very well (around 50% of the width of a flat gear vs >75% of the gear we are using).

The issue we had with setting up the encoder that way was the possibility of having to take off the sensor or doing maintenance on the chassis which could throw off the absolute encoder value. It would make remounting the sensors a big pain, especially during competition.

system · January 5, 2020, 7:50am