Severe Issues with Andymark Swerve and Steer Module
 

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.::ouch::

Re: Severe Issues with Andymark Swerve and Steer Module
 

Huge problems? I'd rather have to start with the wheels rotated the correct number of times than have to zero to a sensor. Just mark a line across the two gears where you want the wheels to be at "zero", and then make sure that you start the robot with the lines approximately lined up.

Re: Severe Issues with Andymark Swerve and Steer Module
 

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.

If anything that ratio gives the sensor extra sensitivity to wheel orientation.

Re: Severe Issues with Andymark Swerve and Steer Module
 

Either I'm misunderstanding you, you're misunderstanding gears, or there's something unusual about the configuration of that device.

Considering continuous rotation in one direction, and simplifying the possible permutations of gearing for the moment, the gears will always be in mesh and rotating together at the same pitch circle speed (with angular speeds varying according to the ratio of pitch circle diameters). In other words, the zero point is not about the alignment of any particular tooth with any of 3¹/₃ teeth. Instead, it will lie at a discrete point and will be repeatable, because the rotation of the gears is proportional.

Now in actual fact, there's a bit of backlash in the geartrain (i.e. a small angle through which the gears rotate without engaging, until the opposite sides of the teeth make contact). This becomes evident when you change direction. Maybe that's what you're seeing? It might also have something to do with overshooting and overcorrecting in your centring algorithm.

Also be aware that those sensors treat zero as a discrete digital value based on the encoder's resolution, and you can read back any deviation at a much finer level than the number of teeth you have. (Many of the common absolute encoders are 10-bit, which means 1 024 counts per revolution.)

Re: Severe Issues with Andymark Swerve and Steer Module
 

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.

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...

Re: Severe Issues with Andymark Swerve and Steer Module
 

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.