Severe Issues with Andymark Swerve and Steer Module

[TheOtherGuy]

Originally Posted by Elfonzo

I find it necessary to alert all teams who have already purchased the Andymark Swerve and Steer Module of issues in its performance. Andymark is offering a better, "absolute zero," (as we like to call them,) sensor. This "better" sensor always has a point it can refer to as zero, eliminating the need for pre match centering/zeroing. However, because the gear that the sensor is attached to and reading from is 12 tooth, and the gear used for turning the assembly is 40 tooth, the sensor has effectively 3&1/3 "zero's" This causes HUGE problems when trying to read the position. If you have not completed your electronics board and given the programmer(s) a chance to test it, be prepared to come up with major issues.

You will definitely have a problem trying to get the current angle of the module when you first turn on the robot (3-1/3 rotations/module rotation = 10 zero-ing angles), which is why you'll need to make sure the wheels are aligned before grabbing the initial position of the encoders.

You can get the current position by keeping a running sum of the encoder ticks, making sure to add the right change when it wraps around a zero point. Get the position by calculating the modulus of the total encoder ticks in a full module rotation (resolution * 3-1/3) and the current value. If you run over (or under), be sure to wrap around past the other extreme.

Originally Posted by JesseK

There's a local team who started swerve on Day 0 for the first time ever. They got it up and running with programming by the end of Week 3. They're using AM's product, but haven't reported a problem zero-ing it out since they're good about pre-aligning the wheels to each other at the start. They're using CAN via the Talon SRX, and it works incredibly well.

I wonder if they're using the hall effect encoder? http://www.andymark.com/product-p/am-2816a.htm
Which would make this much more trivial*, given the position is accumulated on the SRX and one simply needs the total encoder ticks per revolution of the module.

*Well, not trivial...

[Elfonzo]

I realize that there are ways to fix the issues we are having, and am not here to supply them. I am simply letting teams know that using "ticks" to count the number of rotations or various other ways of fixing the issue via software reduce the functionality of the "better" sensors to the level of the original, relative, sensors, because you still have to align the wheels before each match. Because of the new brownout protocols, the sensors can loose power and completely mess up your pre-match alignment. This is what the absolute sensors are supposed to eradicate.