Fixing AndyMark's Swerve & Steer Module Problem

[Tom Line]

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]

http://www.chiefdelphi.com/forums/sh...09#post1439709

[marshall]

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]

Originally Posted by Tom Line

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.

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]

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]

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]

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.