Our drive system is based on the MK3 and MK4 example code: https://github.com/SwerveDriveSpecialties/swerve-lib
When we run without the CANcoders it seems to work fine, minus the fact that you have to set the wheels before you start. When we add the CANcoders we start fine, but eventually, all the wheels become misaligned.
The magnets are all lock-tighed in, and we tried this change to make sure the CANcoders boot to absolute discussed here: Official SDS MK3 & MK4 Code - #99 by Zach_O
Our code can be found here: https://github.com/WOFsoftware51/FRC-2022
Pictures of our CANcoder values while driving the robot straightish forward while on blocks. You can see the inconsistencies in the absolute values:
Hello, Sorry I’m new to frc and robotics this year, so sorry if I can’t help. I’m from team 4610 and we are using swervelib too, I noticed some minor things which wouldn’t explain the issue with the encoders but cause the wheels to fight each other. Offset Link (The encoders are relative to the wheel so the corrected position is AbsPos + Offset)
for us we had an issue with a drift + field orientation being off caused by Magnet sensor being calibrated without actually calibrating Link
as it recently looked like you committed a fix by changing BootToZero to BootToAbs did this fix the issues you were encountering?
Did you find a solution to this problem? We are having a very similar issue.
Be sure you have the latest CANCoder firmware. There was a recent release:
Phoenix Framework 126.96.36.199 (Aug 19 2022):
Phoenix Libraries: Added diagnostics config support for CANcoder vH
CANcoder Firmware (188.8.131.52): Additional integrity checking on bootup
CANcoder vH Firmware (184.108.40.206): Version of CANcoder firmware to support vH chips.
There are several existing threads that cover reports of similar symptoms. It would be good to start there, and report status after doing this and trying the suggestions.
Is there a link to the current version? The one on the CTRE website is still the 5.21.2 March 18 2022.
The CTRE GitHub has it.
Phoenix Framework v220.127.116.11
Based on the release notes, it seems unlikely that a firmware update will address the problem, but it’s certainly worth a try.
I would start by going back to just the SDS and see if it still happens. Then you have eliminated your change to swerve lib if it still happens or implicated it if it doesn’t .
I haven’t dug through all your code but i did notice you were resetting your encoders in your auton, not sure if you are doing it elsewhere. We never reset our encoders. We update and reset our pose but never our cancoders.
I talked to CTRE. The update is actually for the new cancoders (just now shipping) They had to substitute a chip because of chip shortage. They said the update does not effect the older cancoder. There is a blog post coming out about it.
It installed for me just by doing a vendor library update from Visual Studio. If you are on the next latest version, it might not make a difference – if you are further behind or, if you happen to have a newer CANcoder with the chip that’s supported by this update I’d update. In general, I like to stay on the latest release but keep the one which was being used around, just in case there’s a need to roll back.