REV Through Bore Encoder Jumping and multiple rotations

Technical Java
1

I have two through bore encoders on our robot, one of them is connected directly to the shaft of our arm, and the other in on a belt driven extension. I have the arm encoder calibrated for 0 degrees to be level, but instead of going up when it goes up, and down below 0 when it goes down, it skips to 360 then starts going down. Is there a way to convert these values to increase and decrease from 0? or do I have to have the 0 position somewhere else?

The extension encoder rotates about 5 times on the extension, but it will only read the rotational position, but I want it to count the number of rotations. Is there a way to do this while still having it be absolute and connected directly to the SPARK Max?

2

For the encoder monitoring your arm rotation angle 1:1, you can move the “0” position on the encoder as far away from your desired 0 position as possible - preferably to a real world angle where your arm can never reach. Look for the notch on the white plastic hex circle to line up with the notch on the black plastic case - that is your zero trip point.

Using offsets and such, that should let you have a continuous range of angles through your desired “0” location that doesn’t “flip”, and you can adjust the values to report how you want for your code.

For tracking numerous rotations (such as on your extension arm) without the encoder resetting every rotation, I asked the same question of REV support, and this is a feature option they would like to implement in the future when using the Absolute Encoder Adapter tied directly to the SparkMAX. But not this season.

Connecting the sensor directly to the RoboRIO in pulse width duty cycle mode DOES give you the desired cumulative function that you described, FYI:

Scroll down to “Duty Cycle Encoder (Absolute)” to see a RoboRIO DIO connection diagram.

1 Like
3

Sounds like an application where you could use a 10-turn potentiometer.

4

How will it know how many times its rotated between power cycles?

5

I was able to get it to run in relative mode, but when I get inconsistent values at the same positions. For example, if I fully extend it, it will read 4.8, then I bring it back in, then back all the way out, and it will be 5.2. There is no slipping , the rotation of the encoder is directly linked to the extension of the arm

6

This is my implementation to solve effectively the same problem:

if (lastPos < FourBarConstants.SHOULDER_FLIP_MIN.getRadians() + 0.1 &&
 absoluteEncoder.getPosition() > FourBarConstants.SHOULDER_FLIP_MAX.getRadians() - 0.1) {
      counter--;
} 
else if (lastPos > FourBarConstants.SHOULDER_FLIP_MAX.getRadians() - 0.1 && 
 absoluteEncoder.getPosition() < FourBarConstants.SHOULDER_FLIP_MIN.getRadians() + 0.1) {
      counter++;
}
lastPos = absoluteEncoder.getPosition();

Then you can get updated position with counter through:

armPositionRad = absoluteEncoder.getPosition() + counter * (FourBarConstants.SHOULDER_FLIP_MIN.getRadians() * -1 + FourBarConstants.SHOULDER_FLIP_MAX.getRadians());

Effectively we are trying to figure out when the encoder flips and we will increment a counter when the happens to compensate. We can then use the count of the counter in addition to our absolute encoder position to determine the position of the mechanism. The only restriction of doing it this method, is you have to be 100% sure that the mechanism is in a known position when you are starting the code, or you have some zeroing mechanism otherwise bad things will happen.