Question on Swerve

The last time my team used swerve was in 2015, Recycle Rush, and we used screwdrivers to lock the wheels in place so the code sets where 0 is on the encoders.
I was wondering what systems do other teams use to keep the wheels pointing at a set direction?

Typically this is done with an absolute encoder.

Many teams are using a CTRE CANcoder, CTRE Mag encoder, or TTB absolute encoder.

3 Likes

The most common current approach is to use absolute encoders to either determine wheel rotation at all times or to initialize relative encoders built-in to brushless motors.

3 Likes

Another approach is a hybrid approach. initialize relative encoders built-in to brushless motors on startup then update/correct them when the robot is stopped for a brief period of time.

2 Likes

Does your team periodically correct relative encoders on motors? Do you find that the motor encoders have dropped/added counts and lost calibration? If so, to what extent?

WE do not, or if we do it is in SDS code not ours.

I saw that approach in another thread as a potential fix for issues of being off. We were not experiencing those issues so I did not pursue the issue. I just thought it was worth mentioning if you were concerned with using the brushless encoders entirely.

I occasionally reset the angle of the modules and this resulted in some compounding error until after a few resets, it was off by several degrees. I’ve never experienced any significant angle drift over the course of several minutes.

Here’s a sort of summary what you and others experience as noted by all the fine posts above this. We use TalonXXX so convert to whatever brand you use.

You have to align the encoders to the wheels (get the correct side of the wheel forward) whenever the structure or any component mounting changes. My team does that by wedging a small block of exactly the right size piece of wood or plastic between the wheels and the chassis. There are CD posts about fabricating such a block but our approach was a little more crude trial and error and couple of times.

You have to align the chassis/wheels to the field for match play and various schemes are used. The students got pretty good with practice of eye-balling it with start position field floor tape. Last season the angles were tricky but they did very well. Other jigs and measuring tape may be used as long as you don’t hold up the start of a match. (See various CD posts.)

A simple statement of our reset code in Talonese as others have mentioned:

    turnMotor.setSelectedSensorPosition(0.0);
    turnEncoder.setPosition(turnEncoder.getAbsolutePosition());

You can manage the magnets’ offsets in code or in the CANcoder (using the Phoenix tuner)

To another poster’s point (@paulonis ) we find that different position accumulators (memory of all the many thousands of tiny additions and subtractions or movements) vary in accuracy because of round-off or lack of enough significant digits errors. IIFC (and that’s a big IF - check it for yourself) it was the CANcoder that although highly accurate relative to the magnet did not accumulate the tiny movements accurately and was useless fairly soon after a reset; that’s why we use the motors’ encoders.

Another issue with encoders (such as the CANcoder and others as a question posted on CD) is their maximum speed and that can be seen on a flywheel mechanism or drive motor like a turret and not on a turning motor.

The new inductive encoder from WCP solves the module zeroing problem once and for all and turns it into a set it and forget it situation. I’m stoked for it to come out.

1 Like

Maybe someone can explain to me how this is different from the mag encoder solution. The big problem with that (for us at least) isn’t that it’s belted to the module, it’s that you can’t plug the encoder into a Falcon. You have to either have it connected by CAN (which is slower and puts load on the bus) or connect to the RIO and only use it periodically to negate drift. How does an inductive encoder help solve that problem?

@R.C can explain better