Help with alternate encoders for NEOs

Technical Sensors
#1

So my team is starting to move away from falcons (as much as i love them) considering their stock availability and how 5 falcons is like 20 NEOs. One problem that I’ve encountered so far on the technical side of using NEOs is that their integrated encoders are just meh.

I’ve heard many good things about the 63R256 shafted encoders are very nice but they are sold out EVERYWHERE oh my days.

So I’m wondering if anyone has any suggestion because right now im considering 3 options: The Rev Through Bore encoder , ctre MAG encoder (dont know how that one gets wired), or some other greyhill encoder at a lower resolution probably since all the 256 ones are out. Any input would be appreciated.

1 Like
#2

I would highly recommend the REV Through bore encoder- it’s as high resolution as you’d ever need and is very well priced, and dead simple to use- stick it on a hex shaft (or 1/4" round shaft, it comes with adapters). The CTRE mag encoder can also be used as a quadrature encoder, although it will require adapting the wire to match the Spark MAX data port pinout or to be wired to the RoboRIO. It’s also very high resolution and easy to use with many COTs gearboxes.

We’ve used the 63R256 encoders for many years and like them a lot, however they’re harder to integrate into cots mechanisms than the REV throughbore encoder, and their price is hard to justify in comparison. I wouldn’t recommend them to anyone looking to buy encoders for FRC nowadays.

I’ve also found that the NEO integrated encoder is perfectly fine for most things- velocity control on low inertia mechanisms being the glaring exception. While it is low resolution, it’s almost always going to be behind a gear reduction, increasing the resolution of the encoder over the mechanisms travel.

5 Likes
#3

Im relieved the Through bore encoder turned out to be good because it really does look like the simplest to use. When you say the NEO integrated encoder is fine for most things does this include odometry (trajectoryfollowing etc)?

#4

The biggest complaint I’ve seen is with velocity control because of the 100ms delay. But positioning you will get error with the slop in the gears. But nothing major from what I have heard

1 Like
#5

I’m currently working getting odometry and trajectory following working with the NEO integrated encoders. The problems that I’m having are definitely not with the encoders. (This could change as I test further though) I used them during the 2022 season for positional PID control on our drivetrain and it worked great. Very consistent and accurate. REV also provides very good example code for use with the encoders.

Spark Max API information
https://docs.revrobotics.com/sparkmax/software-resources/spark-max-api-information#java-api

C++ docs:
https://codedocs.revrobotics.com/cpp/namespacerev.html

java docs:
https://codedocs.revrobotics.com/java/com/revrobotics/package-summary.html

#6

I’ve found that NEOs are typically fine for drivetrain odemetry because of the gear ratios that you usually run on the drive train. This increases the resolution of the NEO by quite a lot.

1 Like