VersaPlanetary encoder underflow position with Spark Max brushed motor

Our robot has an arm using a VersaPlanetary Integrated encoder on a CIM motor. I first plugged it into a TalonSRX and I was able to read values just fine (from what I remember). I then swapped that motor controller to a Spark Max to share the same code with another joint of the arm using a Neo 550.

The main problem I’m facing is that the encoder doesn’t display negative values (because it’s a quadrature encoder). The weird thing is that when it goes below 0, it goes to a value like 2400, which I didn’t expect since the encoder has a counts per revolution of 1024. I don’t believe I had the same problem with the TalonSRX; I can’t test it right now without the robot. If it were to underflow to 1024 or some other sensible number, then it would be an easy work around in code.

The encoder is plugged into the Spark Max data port - Here is the code for getting the position…

self.armMotor = rev.CANSparkMax(
    constants.kCANId, rev.CANSparkMax.MotorType.kBrushed

self.armEncoder = self.armMotor.getEncoder(
    rev.SparkMaxRelativeEncoder.Type.kQuadrature, 1024

# converting to degrees
)  # kConversionFactor = 0.5532
    * (math.tau / 60)  # converting from RPM to radians per second

# periodically...
print("Arm pos:", self.armEncoder.getPosition())

Unrelated, but some feedback on the velocity conversion factor would also be appreciated. I’m unsure if that math is correct.

When the code is run and the encoder ticks backwards slightly, the value jumps up to ~1216 deg with that encoder ticks → degrees conversion applied.

I’m thinking about switching back to a TalonSRX to first see if the issue is the same, else I’ll think about swapping the CIM for a Neo or Falcon.

Is there other Spark Max configuration I missed? Did I get the encoder wrong? I believe kQuadrature was the only one that worked and didn’t display 0 deg.

We ran into this same issue. We just set out starting position to half of that crazy high value and base everything off of that to ensure that negative issue doesn’t occur. This is just inherent in how quad encoders are handled on the SparkMAX. As for the unrelated one, the math looks fine at first glance but if more issues pop up don’t hesitate to ask.

haha this was also my quick workaround. It works since the arm we have doesn’t wrap around itself infinitely, disregarding the need for an absolute encoder. I really wish they had a solution to this. There probably is, but we’re not seeing it now. A reply from REV would be cool.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.