Our team has CTRE SRX absolute encoders plugged into cansparkmaxes with a breakout board on our Swerve Drive rotation motors, but as the motors spin, the absolute encoders drift. For example, after several rotations, the encoder position when straight drifts. As it rotates in reverse through, the drift decreases again, down to 0 or below. Anyone know of any solutions or if we are missing something or why its drifting so much?
p.s we tried spinning it when the robot was off and on and saw the same drift issue.
Test driving it around for a couple minutes we also saw the drift issue
oh we realized what you meant by magnet. We took the absolute encoders off and ensured the magnets under were secure and they were. Thanks for responding by the way.
if you plug the encoders into the roborio instead, does it work as intended? you’re probably not gaining that much by using the controller for absolute position anyway.
Trying to plug into the rio is not something I can do immediately right now because our electrical team isn’t around and I think it requires soldering. But it is something we’ll try eventually.
Quick update: After some more testing we also found that the drift starts to go to zero if we spin the angle motor the other way. E.g we spin it clockwise a couple times and then spin it counterclockwise a couple times, the drift goes to zero
this might sound funny but I’ve seen this kind of error as a result of a mistyped constant, e.g. degrees per turn = 350. where are you observing the measurement?
The sparkmax itself, conversion factor applied of 360, should be readong between 0 and 1 without conversion factor applied inside YAGSL. Really shouldn’t be this, but maybe?
The measurement is being observed within the absolute encoder tab of rev hardware client. Last time I checked I’m almost 100% sure that the conversion factor was set to 360 whenever we were trying to figure out where the drift was coming from. I will check again when I go in today, and honestly hoping that is the issue and I can get on with other things lol.
And for YAGSL, the swerve library we’re using, I will say we never directly looked at the drift through the encoder readings YAGSL puts on shuffleboard. We only noticed the motors became off when doing drive practice, and then confirmed it was drift through the rev hardware client.
Going in today, I’ll also try hooking the absolute encoders up to the pwm ports on the rio and seeing if the drift still exists then.
Thanks for all the help by the way! I really appreciate it.
I don’t think there’s anything i should do to fix this, jowever if you wanted to change the average depth for the sample size that may be the best option. I will never implement that inside YAGSL itself bc that’s a very specific thing.
What do you mean by the “average depth for the sample size” and why would that fix the issue? Embarassingly, I kinda have zero sense as to what your talking about