Rev Though Bore Encoder Jump(scare)

During our first competition, we noticed something that never happened during testing. The wrist, connected to a REV Through Bore Encoder, would slam down completely randomly. At first, we thought it was caused by heavy collisions, as the jump occurred most frequently after hitting something at a high speed. However, it’s also happened multiple times after we lightly bumped into a note during an auto, so it seems to be more random than we initially thought. We looked at the logs and found that the issue was not due to the encoder resetting, but rather a jump in the reading.

The reading would be stable, but then randomly jump about 1.5 radians. It has consistently jumped by this much, although it has occurred almost exclusively at competition. We have implemented a failsafe, but are curious as to why this happens and how it can be fixed.

We have a similar problem too. The encoder jumped up by 1 revolution for no apparent reason. Disabled and enable the robot again, and the problem no longer occurs. We weren’t able to recreate the problem.

We are 90% sure it is not a wrap around issue, because the encoder worked as expected before and after this run without hardware or code changes.

REV Through Bore Encode with the class DutyCycleEncoder, and we are using the .get() method. Units are in degrees (just .get() * 360)

1 Like

Same here — the jump usually happens while the wrist isn’t moving, and wrist regularly moves further in both directions from wherever the jump occurs without problems.

Same issue. Sometimes it’s the encoder itself reporting a zero or a bad value and sometimes it’s the RIO itself reporting zero for anything connected to the DIO ports. The reason I know this is that we 2 through bore encoders on the robot at opposite ends of our arm axle as backups of each other. In the logs we clearly see during a loop of periodic BOTH encoders simultaneously report zero. That has to be a RIO issue in that case.

We only use the encoders on robot start up once. Using the angle they report we then set the encoder position of the SparkMax controlling the arm to the position it would be at that that angle.

Then we control the angle of the arm just by seeking an encoder position on the SparkMax.

We then monitor the SparkMax for failures and shut down the arm if it fails. That hasn’t happened yet.

1 Like

We are also intermittently experiencing this issue. I think there is enough reports here that there is something to this.

We are wiring our throughbore directly back to a SparkMAX and still experiencing this issue so I don’t think it is directly RIO related.

Is there any chance this is noise related? What is the proximity to nearby motors? Has anyone talked to REV about this?

I just saw this same issue Saturday while at competition while checking things over in our pit. We were using the encoder as an absolute to know whrn to stop rotating our shooter until i saw this odd behaviour and removed it from the logic. I thought maybe I was going nuts seeing things wrong. Nice to know others are seeing the same issue.