This year my team used CANCoders for our swerve modules to get the rotation at the start of the match. Unfortunately there is an issue with them where they don’t initialize properly a significant amount of the time, to the point where sometimes they just won’t initialize at all. As many of you with CANCoders for swerve know this makes them basically useless because you can’t trust them. We asked team 1102 for help and they gave us a solution that they had worked on with CTRE that doesn’t fix the issue but minimizes it. They basically just said align them manually so if it does happen you are functional. While the solution helped significantly, it did not eliminate it the issue to an extent that our team would like. We basically might as well not have had them. I would like to look into using through bores instead. Has anyone had issues with the absolute encoder on them? Is there any specific thing I need to know about using them?
Have you contacted CTRE support? It could be a bad batch of CANCoders, or some configuration problem.
This is a known issue with CANCoders. If you want more information then you can look at 364s basefalconswerve issue 8. It is unfixable but on our side and as I said, 1102 contacted support and they couldn’t fix it either.
Have you tried this fix?
I don’t believe it to be a CANCoder problem, I have never faced this issue in all my swerve development.
Yes that is what we were doing and we were getting the issue almost every other time we deployed code or turned on the robot.
Are your cancoders in absolute position mode? We had the exact symptoms as you until an undocumented line of code was added to change the relative encoder functionality to absolute.
absoluteEncoder.configSensorInitializationStrategy(SensorInitializationStrategy.BootToAbsolutePosition, 1000);
We used the REV Through Bore encoder on our swerve modules this year and found that they drifted a lot over the course of just a few matches. Stick with the CTRE encoders and try to iron the issues out there.
This was actually an issue on the old SDS code. Could be the problem everyone’s facing.
What do you mean drifted? The sensor itself is absolute, it doesn’t drift. If you noticed the zero moving its likely to be a mechanical coupling issue, or perhaps a software issue.
We had a similar issue with one of our REV encoders. We had it in absolute mode on our arm and during our first event, it “drifted” quite a bit. While on the practice field without restarting the robot code, the encoder drifted 30 degrees. It definitely wasn’t physically moving that far out of sync with the arm shaft (mechanically coupled and no skipping teeth/chains). We eventually replaced the encoder with another one and have had no issues since.
They are in boot absolute position mode, but we don’t have that line of code. What is the 1000 for?
I am inclined to believe this is not the issue because we used boot to absolute position and the get position function in a post that I can no longer find that suggested the solution to the issue.
1000 is the timeout (in ms) for the config to report a change. I suppose it could be lower, but why?
To be clear in our config, we are running PID on the roboRio and not Spark MAX, so this config directly relates to what the CANcoder is reporting to our roboRio closed loop control
We bought our CANCoders early this year (January-ish) for our swerve, and have never experienced this problem. If it is just a bad batch problem, then buying new ones should fix the issue. Even though it is a known issue, it’s not a common issue. This leads me to believe it’s most likely a problem specific to the few robots it is happening to, not the cancoders themselves.
Yeah, for some reason the REV Through Bore will “drift” though and we weren’t the only team with this issue. We eventually swapped it out for another solution, but we had discussions with 3 other teams with the same REV Through Bore “drift” so it is definitely a known issue.
Uh is it known to rev? I’ve never noticed any drift with a through bore mounted to an arm all season.
No idea. We never bothered to contact support since it was past the 30 days and we were able to get a limit switch like zeroing routine working more reliably over time than the absolute encoders. But that’s a good idea, now that the seasons over we will contact support about our issue. Edit: (we were using the ‘getAbsolutePosition()’ method if anybody was wondering)
News to me… and we have 5 of them on this year’s robot (and have used them in the past with no drift)! I’m sure REV would want to hear about it, even past the 30 days - they may even want it back so they can do root cause on it to figure out why it’s not working right.
Could you explain more I’ve never heard of this issue?
We found that the glue connecting the bearing to the hex shaft adapter might be the issue. It may just be an issue with where/how we mounted it, but then again we weren’t the only team with the issue that we talked to at local comps.