REV Through Bore Encoder woes

Technical Sensors
, ,
1

Hi y’all, I’m Dhinak, head of programming from team 1155. First post here (yay!).

My team has been having some issues with the REV Through Bore Encoder. We’ve been attempting to use it as an absolute encoder in order to be able to adjust the angle of our hood for our shooter this year. Our team has had past experience with these encoders before, but because it was during COVID, it was minimal and most of my department doesn’t have this experience. I certainly don’t remember having this much hassle in dealing with them.

The main issue we’ve been experiencing is that the output we’re getting from the encoder has not been consistent: sometimes when we bottom out the hood we get the output as 19 degrees; other times, it’s 2 degrees. The range does appear to be consistent (roughly 25 degrees), although I would like to double check tomorrow.

We tried several things like making sure the cable has been connected properly (DIO ports, white wire) and using reset in order to reset it to 0. However, it hasn’t been going that great (we tried calling reset but it appeared to have no effect for some reason??).

Since we are running low on time (load-in is 2 days away!), we decided to try a little workaround: assume the hood is already at the bottom, read the current output and store it to be treated as an offset, then adjust our code to subtract this offset when reading from the encoder. However, due to unknown reasons, this didn’t work either; we just got the same results as before.

Our working theory is that initializing the encoder takes some (miniscule, but still enough to make a difference) time and since we’re reading the encoder output right after initialization, we’re reading 0 instead of the actual value, and so our offset ends up being 0. However, due to time constraints today, we weren’t able to validate our theory.

Our next steps for tomorrow are to:

  • Insert a delay between initializing the encoder and reading to get the offset
  • Swap out the encoder for a new one (and test the old one with a test board)

Is there anything else our team should try in order to debug this issue? For reference, we’re a Java team and have been using the DutyCycleEncoder class and the getDistance method. We’ve been scaling the output into degrees using setDistancePerRotation.

Thanks,
Dhinak and the rest of team 1155

3 Likes
2

Try using getAbsolutePosition() and see if that value is consistent. That function is new in WPILib 2022.4.1

For that function reset() has no effect, but it gives you the correct absolute position, where getDistance() gives you the distance since the last reset/power on.

Also, what is the gearing between the through bore and the hood angle?

1 Like
3

We are also using the Rev encoder for hood angle and it’s rock solid. I’ll ask how the code was done. Ours is directly on the hex shaft driving the hood.

There is a small slide switch on the side of the encoder body. That switch must be in the A position for the encoder to work properly. The S position on the switch is for some future serial interface, IIRC.

4

I believe we’re using the getAbsolutePosition function with ours (on our intake). It’s rock solid, gets our intake exactly where it needs to be every time. It’s right on the rotation shaft, so no conversions need to be done - just a little testing to find the exact values for the presets we needed. The biggest benefit to that is that the values and positions are consistent. We wouldn’t want to be dealing with having to reset the angle to zero, too big a chance that you get off and then try to overextend at some point!

5

Just to be sure its not a mechanical issue, you are running the hex shaft through the encoder? Ive seen teams turn down the end of a shaft. press on the 1/8" to hex adapter and use the encoder that way. This could lead to slipping between the nipple and the adapter.

6

We use the getAbsolutePosition() method rather than getDistance() as I think the latter is for the relative encoder mode. I’d recommend making a method that returns your scaled value instead.

7

It does indeed take a bit of time to get valid results. Something like 200 milliseconds. Which means in Java you can get 4+ bad readings before you get good readings. To be sure that the DutyCycle pulses are up and going properly, we queried the encoder using the function isConnected(), and we don’t read the values until it returns true.

8

Thank you for all of your comments! We decided to not replace the encoder and use getAbsolutePosition() (with some math to scale the output) like a few of you have commented, and so far with our testing, it’s been consistent!

This sounds about right, we are indeed experiencing a bad reading (of around 22) until it stabilizes after a few ticks to the correct reading (36). We will try isConnected() like you’ve suggested, although this behavior isn’t really an issue anymore now that our output values are consistent.

9

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