Swerve Modules not lining up

ematt2169 · February 2, 2024, 11:42pm

We have been trying to line up our swerve modules for a few weeks now, but we can’t get them to sync up. We are using mk4 swerve modules with falcons for driving and neos for steering. Please let me know if there is anymore information I can provide as this is my first post to Chief Delphi. Thanks!

github.com

KINGTeC2169/2024-Robot-Code/blob/Development/src/main/java/frc/robot/subsystems/SwerveModule.java

package frc.robot.subsystems;

import com.ctre.phoenix6.configs.MagnetSensorConfigs;
import com.ctre.phoenix6.configs.TalonFXConfiguration;
import com.ctre.phoenix6.controls.VelocityVoltage;
import com.ctre.phoenix6.hardware.CANcoder;
import com.ctre.phoenix6.hardware.TalonFX;
import com.ctre.phoenix6.signals.InvertedValue;
import com.ctre.phoenix6.signals.SensorDirectionValue;
import com.revrobotics.CANSparkMax;
import com.revrobotics.RelativeEncoder;
import com.revrobotics.CANSparkLowLevel.MotorType;

import edu.wpi.first.math.controller.PIDController;
import edu.wpi.first.math.geometry.Rotation2d;
import edu.wpi.first.math.kinematics.SwerveModulePosition;
import edu.wpi.first.math.kinematics.SwerveModuleState;
import edu.wpi.first.math.util.Units;
import frc.robot.Constants;
import frc.robot.Constants.Conversions;

This file has been truncated. show original

github.com

KINGTeC2169/2024-Robot-Code/blob/Development/src/main/java/frc/robot/subsystems/SwerveSubsystem.java

package frc.robot.subsystems;


import edu.wpi.first.math.geometry.Pose2d;
import edu.wpi.first.math.geometry.Rotation2d;
import edu.wpi.first.math.kinematics.SwerveDriveKinematics;
import edu.wpi.first.math.kinematics.SwerveDriveOdometry;
import edu.wpi.first.math.kinematics.SwerveModulePosition;
import edu.wpi.first.math.kinematics.SwerveModuleState;
import edu.wpi.first.networktables.GenericEntry;
import edu.wpi.first.wpilibj.shuffleboard.BuiltInLayouts;
import edu.wpi.first.wpilibj.shuffleboard.BuiltInWidgets;
import edu.wpi.first.wpilibj.shuffleboard.Shuffleboard;
import edu.wpi.first.wpilibj.shuffleboard.ShuffleboardLayout;
import edu.wpi.first.wpilibj.shuffleboard.ShuffleboardTab;
import edu.wpi.first.wpilibj.smartdashboard.Field2d;
import edu.wpi.first.wpilibj.smartdashboard.SmartDashboard;
import edu.wpi.first.wpilibj2.command.SubsystemBase;
import frc.robot.Constants.DriveConstants;
import frc.robot.Constants.ModuleConstants;

This file has been truncated. show original

JonathanL · February 2, 2024, 11:53pm

It looks like your CANCoder offsets are not set correctly in your Constants File.

The way to get the correct offset values is as follows:

Run robot code and press fwd on the forward joystick. The angle values (shown in Smartdashboard or Phoenix Tuner) should be ~0. (Factory zero)
Align all wheels forward. Use an extrusion, or something straight, to guarantee alignment between front and back wheels. Jot down the new angles.
Subtract first angle from new angle, and set that as your offset. If the direction of spin is wrong, add 180 to your offset.

ematt2169 · February 3, 2024, 1:16am

I just finished trying that and it didn’t seem to work. It seems like every time the robot is power cycled or new code is deployed, the zeroed position changes. We tested to see if the absolute encoder is giving accurate values, and it seems to be.

gdefender · February 3, 2024, 4:25am

It’s probably a good idea to verify everything is set up like you think it is. I have a feeling your motor and CANCoder might be out of phase.

Use Phoenix’s Tuner X to verify your CANCoder value gets larger when you turn the wheels CCW (to the left).
Use REV Hardware client to confirm your motor’s position also gets larger when you turn the wheels CCW.
Finally, verify that when you apply positive power to the turning motor, the wheels turn to the left.

When things are set up right, after your code starts up and your resetEncoders() methods have run, the CANCoder and the motor’s encoder should have (almost) the same values as you turn the wheels.

JonathanL · February 3, 2024, 2:50pm

Ohhh ok. We ran into the same issue this year. Setting to absolute mode in code seemed difficult and different than last year. We gave up and went back to Phoenix 5, where you can easily set to absolute mode in the GUI.

Zaheelee · February 3, 2024, 8:46pm

Not a code solution, but just in case this might be your problem: make sure the magnets used by the angular motor encoders are glued to the swerve module itself. The absolute encoder values are dependent on those magnets being very very still, and if they move around your values will go nuts. My students had the same issue as you last year and they went away the moment the glue cured

ematt2169 · February 3, 2024, 11:08pm

We’ve triple checked to see if the magnets are glued in and I can confirm they are.

ematt2169 · February 3, 2024, 11:09pm

I think that we have come to the same conclusion. Thank you so much everyone for helping!