We are using four SDS MK4 modules with Falcons and CTRE Mag Encoders. I have been trying to program this from a command base template using WPILib, but wasn’t having much success so I tried to use the SDS template. Since we are using Mag Encoders and not CANCoders, I zeroed the modules by hand before powering the robot on. At first the code works as expected, but after a minute or two of driving it around (on a bench) one or more modules gains a very large offset, to the point where when driving straight forward some of the modules can be off by more than 45 degrees compared to the other modules. I wouldn’t think this should be possible with the template code. Could the lack of CANCoders be causing this? Is it another programming issue? Could it be some other issue with the assembly or wiring of the modules? I am at a loss currently, and any help would be appreciated.
We had this issue with our SDS MK4 modules even with using the CANCoders. Our problem was that the magnets weren’t glued properly. I would make a thin sharpie mark on both the magnet and the surrounding structure, and after a bit of testing see if the lines still line up. If they don’t the problem is probably with the magnet attachment
To be clear, the magnets in the absolute encoder? The Mag Encoders were not being used at all, so I don’t think that is the issue here.
We have been having other issues with a Mag Encoder though and this sounds like it may be the issue, so still thanks for the response.
Our robot had this happen several times during competition matches. The SDS template code is not amazing and it turns out their swerve-lib has a dead wheel bug where one module will randomly have the CANCoder offset not properly apply. The solution for us during season was to hack into swerve-lib and bandaid those problems. The solution that actually worked once we got into the off-season was removing swerve-lib entirely and using a WPILib-based solution. You can find a good template for that here: https://github.com/Team364/BaseFalconSwerve
It’s entirely possible that it’s not the issue, but this is the possibility I’m aware of. Part of diagnostics to figure this out is to compare the encoder of the Falcon/NEO to the encoder of the CANCoder. If the values are different, you’re definitely hit by this.
Since the robot didn’t have CANCoders or any other absolute encoder being utilized in this test I don’t know if that could be the cause here. Thanks for the heads up about the SDS code and I’ll read the linked repo and try it on the robot when I next have the chance.
For swerve code 364’s template is the best code I’ve found, and a great implementation of WPILib’s swerve drive kinematics.
I also highly recommend checking out WPILib’s documentation of their swerve drive classes
Is this bug documented anywhere? I know the library is unmaintained, but we’d really like to understand this better.
It is documented somewhat (CTRE CANCoder startup workaround · Issue #18 · SwerveDriveSpecialties/swerve-lib-2022-unmaintained · GitHub), but the reason why it happens is not given because no one can read the library well enough to really understand why it happens or how to fix it. We’ve even found democat’s fork to be faulty in this respect. You’re welcome to read the code yourself to see if you can figure it out, I guarantee you’ll get a headache about 5 minutes in (assuming you don’t code your robot with Enterprise Java techniques).
We have been using this fork fine…
There are several factors at play…
Part of the CANcoder’s API is asynchronous and you don’t know whether the setting have been applied before you are using the the result set. Confuses the absolute position with the relative position.
The delays in CANcoder readings have different update frequencies if it is in abs mode v. rel mode.
The original SDS code sets the CANcoder back to rel mode even if you changed it to abs mode.
Swerve-lib uses the steering encoder in real time and then when it detects the drive base to be idle it re-seeds it from the CANcoder. Which isn’t bad, but because of the above it can mask offset problems.
So, this makes it super difficult to figure out whether you calibration offsets have taken hold or not….
Then add in that if you don’t glue the magnets to the steering shaft the whole system becomes non-deterministic. (Not that it happens….)
While you are calibrating, drive the swerve for a burst then wait. 10s or so. You’ll see modules jump as the steering motors get re-seeded from the CANcoder. Do this a couple of times until they stop moving to random positions. If one or more never stop …. You have a loose magnet.
Power cycling is also important because democat’s code set the default boot mode correctly.
It also attempts to make the non-blocking calls blocking by checking error codes. And it retries this process multiple times.
If we were starting from scratch we’d probably have looked harder at using a different library. This library is great because it is very generalized. However that does make it challenging to figure out what is going on and it doesn’t use a lot of the WPILIB stuff that has been released for swerve.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.