Rev Through Bore Encoder Question

[SB11329]

Hello, I am from FTC team 11329 I.C.E Robotics, we are trying to develop RoadRunner in the off season and we are running into a problem with the Rev Through Bore encoders used to measure our dead wheels. We are using OpenOdometry and after finding significant error in our initial test on the field we switched to putting all of the encoders on one shaft to further explore the issue. Despite this change we still find that we have a lot of error. We have three different encoders and have started displaying the encoder ticks and rotations on the phone in order to better understand or find a pattern in the error.

Our team followed through the steps detailed in the learnroadrunner guide to RoadRunner and cant find anywhere that we have gone wrong. We have swapped the wires, expansion hub, tried and swapped out different control hubs, and tried all the different ports that we could. We only have 3 encoders to try but think that is irrelevant since they are all outputting different values. Has anyone else run into this issue before with REV encoders or when trying to figure out RoadRunnner? Linked below is also our code in GitHub for people to inspect if there is anything small that we could have missed.

Below we show an example of what the phone displays. We have setup a basic opMode that uses Road runners Encoder class and sends the value to telemetry.

Encoder 1: 829,557 Ticks ; 101.26 Rotations
Encoder 2: 833,591 Ticks ; 101.75 Rotations
Encoder 3: 822,829 Ticks ; 100.44 Rotations

The error can range all the way up to 1.5 percent at most after being run for a while. Sometimes speed appears to impact the percent error, but nothing is concrete. We can turn it extremely slowly with our hands and it can differ drastically, or spin it quickly and in between and the same thing happens. In addition to the displays above, we have also linked a short video to show what we are testing and the display values that show up so that its clear what we have been doing.

At this point we don’t really know how to proceed, or what could be wrong and any help would be great!

Here is the link to the code we are using to test: https://github.com/BHSSFTC/EncoderTest
Here is a link to a video showing our setup: https://youtube.com/shorts/aU9jHgK5y7c

[Weldingrod1]

I think you need to start with figuring out whether your problem is mechanical or electrical. Looking at the encoder outputs with a scope can tell you something about the electrical side.

A way to separate these two questions is to rotate the encoders a known number of times using a mark on the wheel and a matching mark that lines up with it on something that doesn’t move. Another tactic is to spin it forwards a known number of turns and then go back to the zero line and see if you get back to zero position.

Since you’ve set up all three on a common shaft, I’d look at the actual electrical signals. Make sure you aren’t generating too high a frequency for your data acquisition hardware and that you aren’t over-speeding the encoders. Check the supply voltage for the encoders. Make sure that you have the appropriate pull up or pull down resistors at your data aquisition hardware.

One thing to be aware of is that your wheel circumferences may not be within 1.5% of each other.

The carpet to wheel interaction is very complicated and is likely to vary due to -many- factors. This interaction is going to affect the translation between rotations and linear motion. I’d be thrilled to get 1.5% odometry on a robot, but I don’t have enough experience to tell you what is actually reasonable!

I built a specialized measurement system for measuring the amount of coiled steel tubing that we ran into an oil well. It used two extremely precise and well measured carbide hard faced wheels, algorithms that tabulated based on the fastest wheel, active cleaning, significant contact pressure, precision alignment, etc. With -absolutely- everything we could control dealt with, we managed to get a 1 part in 10,000 measurement. The permanent elongation due to plastically deforming the tube as we unrolled it was readily detectable!