CTRE Magnetic Encoders appear to slip under high acceleration

We are having troubles with our VersaPlanetary Integrated Mag Encoder that have us stumped. The VersaPlanetary gearbox stages are mounted to the output shaft of our elevator gearbox. One of the stages contains the CTRE Mag Encoder. The output of the encoder is connected via ribbon cable to a Talon SRX.

The problem is that when the elevator is driven hard (quick starts/stops) the encoder appears to slip causing our preset encoder targets to be lower than expected. If the elevator is driven at a lower speed/acceleration the encoder works perfectly.

We duplicated this behavior on two robots with two different encoders.
Each slip is about ~400 ticks which is ~1/10 of a rotation or 36 degrees. This is ~1/4 inch of elevator travel.
The slippage will build over time until the elevator is inches off its expected height. It only seems to slip in one direction.
Our software uses the encoder is in relative mode.
We dashboarded the pwm counts along with the quad counts using getSensorCollection().getPulseWidthPosition() and found that the pwm and quad counts moved in lock step.
The Talon has firmware version 4.22 and hardware version 1.7.

We are working around the problem by resetting the encoder when the elevator is down on our bottom limit switch.

Any help would be appreciated.

Stupid question, but might cause this. Where is the encoder located in the versaplanetary? Motor side of shaft side? To get an actual encoder reading for the output shaft it needs to be closest to the shaft.

There are two VersaPlanetary sections attached to an output shaft from our gearbox. The output shaft is not the drive shaft. The VersaPlanetary sections are only used for the encoder. The encoder is on the outside section.

Oh okay. Yeah I’m not sure then, not a huge software guy, but figured I would try and help out.

thanks

I don’t have an answer as to why that might be happening, but you could use a switch (mechanical or optical) to reset the encoder value at a certain point. That should at least mitigate the problem, and keep it from compounding on itself.

Thank you, we are doing that now to work around the problem.

1 Like

Have you triple checked that this is definitely an encoder issue and not a mechanical one (ie. elevator belts slipping)? I’ve never had a mag encoder “slip” this much on me before. Considering it only slips on one direction, which I presume is downwards since the elevator is lower than its intended position, it does sound a lot like downwards momentum forcing some mechanical component to slip rather than the encoder itself.

What’s your configured velocity/acceleration? We’ve gone upwards of 30,000 ticks/second^2 for drive acceleration without any major slippage issues.

We are fairly certain it is not mechanical slippage in our elevator. In addition to the encoder we have a string pot mounted to our chassis and connected to our elevator. The encoder slips relative to the string pot.

To say it another way. the string pot consistently shows the same values when the elevator is at a given location while the encoder reports a different value when compared to before the slippage.

Another way to work around the problem would be limiting acceleration. Fairly trivial with the TalonSRX.

At what specific velocity and acceleration are you slipping at (in ticks preferably)? Have you checked to ensure that the encoder LED’s are green?

Yes, we are using motion magic to move to presets which ramps nicely at either end. The problem does not occur with motion magic. Our manual mode (joystick) is where the problem occurs. We are using brake mode on the Talon.

We are not seeing anyone else having this problem so we are concerned that we are doing something wrong somewhere that could have other ramifications.

To where is the end of your string pot mounted? Is it the elevator carriage or does it wrap around the output shaft of the versa? If you’re attaching it to the carriage so that it extends vertically, it makes sense that even if there was mechanical slippage between the output shaft on the versa and the carriage, the string pot would not be able to measure it.

What is the maximum velocity you could theoretically see on the encoder (based on elevator speed)? There are a couple max rotational velocities it can measure:

Though, these are extremely high, so I’d be quite surprised if you’re violating them.

That’s an old firmware. Latest is 4.22. Maybe thst?

Another question then - Are these two measuring the same thing (elevator position/velocity)? If so, any reason not to close-loop your controller on the stringpot, rather than the encoder? Again a workaround, but hopefully good-enough?

I misstated the firmware version number in the original post. It is 4.22 not 1.22. I corrected the original post.

Yes, we have considered switching to the pot and not using the encoder at all. At this point we have chosen to reset the encoder when we hit the limit switch as our workaround.

Thanks for the idea.

We have not done the math on our rotational velocity but we do not think we are close to this limit. Also the problem clearly occurs when stopping quickly not when we are at peak velocity.

Anecdote:

We saw an issue with hall effect sensor where we were picking up noise from the PWM power outputs from the controller. We would get strange offsets depending on how “fast” we ran the motor (essentially more fast = more offset). Separating the digital sensor feedback wires from the motor drive wires made the problem go away.