Troubleshooting bad angle on single MK4i swerve module

I’ve been trying to find the issue on one of our swerve modules for nearly a day now and I thought I’d throw this out there in case anyone has dealt with a similar issue or has any bright ideas.

We implemented SDS MK4i swerve modules with Falcon500 motors. I have it configured so the CANCoder is the remote sensor for the steer motor. Everything was working correctly and I drove it around for about 30 minutes last night before the students showed up. After about an hour of drive practice the front right module steer position is noticeably off, by about 8-10 degrees. I went back through the process of checking the absolute zero offset of the CANCoder, and I made some minor changes to the offset. The commands to the steer motor are correct and the encoder says it’s at the correct position, but the wheel is still off by about the same amount. The code has not changed since I finished testing it and the students took over.

The build team disassembled the module and checked the magnet. It had been glued, and it doesn’t seem to be loose - meaning they can’t get it to move.

There were some sticky faults on the steer motor for LOS from the sensor, but I cleared those and didn’t see the faults again, but the wheel is still off. I also noticed that CAN bus utilization is high, usually staying above 60% and hitting 100% occasionally, but I have no idea what’s normal there.

As I type this out, the only other thing I can think of is to check the reported position from the CANCoder vs what the steer motor thinks the CANCoder is giving as the remote feedback sensor.

Any other ideas? It’s just weird because the difference is always the same amount in the same direction, and I would have expected the offset to handle it. If the magnet WAS moving, I’d expect it to work correctly for at least a little while after resetting the absolute position offset.

1 Like

I believe I found the issue on this. Tomorrow’s testing will prove it out. Using the Phoenix Tuner, I compared the readings that the steer Falcon was getting from the CANCoder vs. the position and absolute position the CANCoder was reporting. So the steer motor was always rotating to the reported position of the CANCoder, and we needed to start with the Absolute position. A call to the method to set the position to the absolute position fixed the issue. I don’t know why we didn’t have this issue earlier and on more than one module, but I’m fairly certain that was the issue.

Again, we’ll drive the robot a bunch tomorrow and even do things like twist the wheel when powered off to deliberately throw the position off.

I believe we’re having a similar problem, robot is unfortunately disassembled right now so I can’t confirm. Did testing prove this was correct?

1 Like

We had a similar issue, and wound up getting some useful info from the frc discord server. I posted some details here.

So far it has worked flawlessly since the code change. We didn’t get to put as much time on it as I wanted, but the driving we did went well.

I tried setting the CANCoder to absolute position, but I am still having the problem and there is still a difference between what the absolute position is and what the talon gets from the CANCoder. Am I missing something?

I would use the phoenix tuner and CONFIRM that the position is what you expect it to be, and confirm that the values your motor is using to determine it’s position is what you expect it to be. I don’t know how you are using the position from the CANCoder, but I’m telling the steer motor to use the CANCoder as a remote sensor. My fix was to call setPostionToAbsolution ( see line 222 here ).
If you are using the CANCoder to set the internal encoder on a Falcon 500, or using external PID loops, etc. you’ll have to check the position values at each step to where you command the motor to rotate to that position. Ultimately that’s what I did. I had to use the Phoenix tuner to look at what the CANCoder was reporting vs. what the steer motor was getting as the remote sensor position.

I am using the same method as you, where I set the CANCoder to be a remote sensor for the Talon. That works, however I am still getting the same problem where the absolute position for the CANCoder and the position for the Talon do not match, even when I call setPositionToAbsolute. Is there something else you are doing to fix this?
Code: https://github.com/Team4028/wpiScratchSwerve

You are calling setPositionToAbsolute early in the initialization of your swerve module, and I’m calling it near the end. Specifically, I’m doing all the config of the CANCoder first, then I call setPositionToAbsolute. I don’t know if that would for sure make a difference, but on line 54, for instance, you configure the absolute offset. If the offset changes from what is already configured that would change your absolute position reading after you’ve already set the position to absolute.

After the module has initialized, before you move the robot at all, you should be able to do a self-test with the Phoenix tuner and see what it’s reporting as the position and the absolute position and it should match. You should also be able to do a self-test of the steer motor and see what IT’S position is reading for PID0 and it should match when you convert the angle that the CANCoder gives to encoder counts. ( CANCoder_degrees * 4096 / 360 ).